http://llvm-cs.pcc.me.uk/tools/clang/lib/Parse/ParseStmt.cpp#1598 is the path for : loops. http://llvm-cs.pcc.me.uk/tools/clang/lib/Parse/ParseStmt.cpp#1640 is the one for `in` loops.

The latter does some ARC stuff that the former doesn't visibly do (http://llvm-cs.pcc.me.uk/tools/clang/lib/Sema/SemaStmt.cpp#109)

ForEach and ForRange AST nodes are created here: http://llvm-cs.pcc.me.uk/tools/clang/lib/Parse/ParseStmt.cpp#1756

ActOnCXXForRangeStmt explicitly forwards to ActOnObjCCollectionStmt() here: http://llvm-cs.pcc.me.uk/tools/clang/lib/Sema/SemaStmt.cpp#2030 So this is definitely intentional.

This code was morally added in http://llvm.org/viewvc/llvm-project?rev=159847&view=rev (it's been touched up minorly since then).

So not sure what you want me to do here. Just WontFix? Add short blurb to https://clang.llvm.org/docs/LanguageExtensions.html ?

#chromium-dev

[12:36:48]  <thakis_>	i’d guess that’s intentional, but file a bug and i’ll dispatch one of my underlings (i.e. me) to hunt down where in the compiler that’s implemented and check if it’s in fact intentional
[12:37:03]  <+ellyjones>	it would be surprising - objc already has its own syntax for iteration?
[12:37:15]  <thakis_>	yeah, but that’s older than c++11 iirc
[12:37:26]  <thakis_>	so i’d guess when they added c++11 loops, they figured “hey why not"
[12:40:54]  <+ellyjones>	thakis_: https://crbug.com/743079 -> you :)
[12:41:18]  <+ellyjones>	rsesek reported that it compiles to the same assembly as if you use "in"
[12:42:02]  <+rsesek>	thanks for filing :)
[12:42:17]  <+rsesek>	I do think it's a bug. ObjC collection enumeration != c++
[12:55:09]  <thakis_>	ellyjones: my underling had a chance to comment on your bug
[12:55:50]  <+ellyjones>	thakis_: so it sounds like this whole thing is WAI
[12:56:06]  <+ellyjones>	rsesek and I were both surprised by it because generally you can't interchange objc and c++ versions of the same feature
[12:56:44]  <thakis_>	ellyjones: not generally true, see e.g. https://clang.llvm.org/docs/LanguageExtensions.html#interoperability-with-c-11-lambdas
[12:56:57]  <+ellyjones>	thakis_: hum
[12:57:02]  <+ellyjones>	well, alright, WNF then :)
[12:57:19]  <+ellyjones>	if we do not want folks to do that in chromium maybe we should add a presubmit checker thingy
[12:58:10]  <thakis_>	ellyjones: why would we not want people to do that?
[12:58:15]  <thakis_>	it’s part of the language
[12:58:16]  <thakis_>	it’s fine
[12:58:33]  <+ellyjones>	I dunno
[12:58:38]  <+ellyjones>	rsesek: do you have an opinion here?
[12:58:49]  <+ellyjones>	I'm generally pro having One Way To Do Things
[12:59:07]  <thakis_>	down with while loops!
[12:59:17]  <thakis_>	and loops! recursion should be enough!
[12:59:18]  <thakis_>	:-)
[12:59:23]  <+ellyjones>	I'm on board
[12:59:24]  <thakis_>	c++ migth not be the language for you :-)
[13:00:21]  <thakis_>	obj-c++ might actually be _the_ language for having at least two do things to do everything
[13:05:39]  <+rsesek>	thakis_: ah I hadn't seen that page you linked. I think ¯\_(ツ)_/¯ is my answer
[13:06:16]  <+rsesek>	if I were supreme stylemaster I'd say use for-in for ObjC collections, use for: for C++ collections. that follows our rules for #import vs #include, camelCase vs under_scores, etc
[13:07:16]  <thakis_>	eh, it’s not that important, and fewer rules is kind of good too. this rule seems like it wouldn’t pay for the mental cost of havng everyone remember it imho
[13:07:20]  <thakis_>	but  ¯\_(ツ)_/¯ is always the best answer
[13:07:23]  <thakis_>	so let’s stick with that


I vote for adding a blurb to https://clang.llvm.org/docs/LanguageExtensions.html and WontFix. Though if anybody votes me for supreme stylemaster, I shall enforce my will :-)