= On Mon, Aug 26, 2013 at 5:36 PM, Howard Hinnant <howard.hinnant@gma= il.com> wrote:

On Aug 26, 2013, at 8:28 PM, Zhihao Yuan= <zy@miator.net> wrote:

> On Mon, Aug 26, 2013 at 8:16 PM, Geoffrey Romer <gromer@google.com> wrote:
>> template <typename iter_t>
>> value_type& GetValue(iter_t iter) {
>> =A0return *iter;
>> }
>
> I think this can be "corrected" by just replacing the return= type
> with `auto` :(

I was going to suggest:

typename std::iterator_traits<iter_t>::reference

but I like Zhihao's suggestion a lot better. =A0Unless you need the ite= rator_traits dance for SFINAE purposes.

Bottom line: =A0All we have to do is stop assuming that *iter returns a val= ue_type&. =A0We already can not assume that for input iterators, do thi= s does not seem like a big stretch. =A0And we already can not assume it for= output iterators, even though we can use output iterators to modify values= ..

Yes, it's _possible_ to rewrite that c= ode so that it works with a proxy. I'm just saying that it's _harde= r_ to write correct code against a proxying iterator than against a non-pro= xying one. It's true that "all we have to do is stop assuming that= *iter returns a value_type&", but the "we" here refers = to all C++ programmers, so this is not a small thing, and undefined behavio= r is a pretty harsh punishment for those who fail to update themselves appr= opriately.

Now, sometimes you need a proxying iterator, because re= turning value_type& just isn't possible. That being the case, it= 9;s certainly preferable for such iterators to be a supported part of the i= terator framework, and it's certainly desirable for them to be able to = describe themselves accurately (e.g. vector<bool>::iterator supports = random access, but can't return a value_type&), so I am wholly in f= avor of decomposing the iterator categories to describe value-access separa= tely from traversal (along the lines of n1640), and relaxing the iterator r= equirements of the standard algorithms as much as possible.

What I don't want is for the STL container requirem= ents to allow proxying iterators or, still worse, for the standard iterator= concepts to permit proxying unconditionally. This would render some existi= ng code incorrect, and worse, it would be incorrect in a subtle way that wo= uld probably work most of the time, because in practice the STL containers = are unlikely to use proxying, so there may be a long lag between when the b= ug is written and when it is discovered.

=A0

Howard

--

---
You received this message because you are subscribed to the Google Groups &= quot;ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e= mail to std-propo= sals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/gro= up/std-proposals/.