"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. | 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. | | 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. 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 -Thorsten