"Thorsten Ottosen" <nesotto@cs.auc.dk> writes:
"Peter Dimov" <pdimov@mmltd.net> wrote in message news:00c101c55591$877dbab0$6401a8c0@pdimov2... | Thorsten Ottosen wrote: | > "Peter Dimov" <pdimov@mmltd.net> wrote in message | > news:02b001c554cd$47504940$6401a8c0@pdimov2... | | [...] | | >> for( [type] [identifier] : [expr] ) | >> [statement] | >> | >> Let e of type E be the value of [expr]. For each iterator i in the | >> range | >> | >> - [ e.begin(), e.end() ) when E is not an array type; | >> - [ e, e + N ) when E is T[N], | >> | >> executes the compound statement | >> | >> { | >> [type] [identifier] = *i; | >> [statement] | >> } | >> | >> | >> | >> doesn't require library support. | > | > but it wouldn't work with pair<iterator,iterator> without an adapter. | | Correct.
and it also makes it harder to treat const char[N] differently.
That's covered by Peter's suggestion.
| I think that the benefits of not having to include <iterator> and | confining this to a pure core extension not requiring library support | outweigh the costs.
Agreed. I like the idea of this being essentially a rewrite-rule. If it calls free functions rather than member functions it starts to depend on what headers have been included, which seems rather fragile.
| pair<iterator, iterator> is not the proper way to express an iterator range | anyway; its use in the standard library only serves to highlight the lack of | iterator_range<iterator>, or even range<iterator>, if you prefer.
still, a lot of code depends on it...it seems really silly that this new construct should be made harder to use for those libraries.
I've never seen any code use pair<iterator,iterator>. Maybe I haven't looked hard enough. Anyway, you could add make_range() to a standard header that would handle the necessary adaptation.
An <std> header is the way to go IMO.
anyway, I'll try to get a discussion on this in Quebec.
| >> One reasonable extension | > | > perhaps. C++ is typed language. | > | >> would be to allow [type] to be omitted, ... | | This form is even more typed than the other, because it doesn't let you | accidentally supply a wrong type.
for( auto i : vec ) ;
will already work
I think that explicitly specifying the type (even if "auto") is a good idea. It would seem inconsistent with normal for if you could not reuse an existing variable, or if a new variable was introduced without a type declaration. Also, IIRC, in C# (or was it C++/CLI?) you can reuse an existing variable. Anthony -- Anthony Williams Software Developer