[ 2023-06; Varna ]

During LWG discussion of this issue it was decided to reduce the priority to 3.

Furthermore, the still presented "Solved by" comment has been recognized as being no longer true, since the referred to pre-C++11 concept paper wording N2758 is no longer part of the working paper.

It also has been observed, that the "convertible to bool" part has since been resolved by P1964 and the follow-up paper P2167.

Also LWG 3105 has a lot of overlap with this issue.

[ 2017-07 Toronto Thurs Issue Prioritization ]

Priority 2; same as 2962.

[ 2017-06-02 Issues Telecon ]

Move to Open. This is very similar to 2962, possibly a duplicate.

Marshall to research

[ 2017-02 in Kona, LEWG recommends NAD ]

Has been clarified by 14. By design. Ranges might make it go away. Current wording for input iterators is more constrained.

[ 2009-10 Santa Cruz: ]

Mark as NAD Future. We agree there's an issue, but there is no proposed solution at this time and this will be solved by concepts in the future.

[ 2009-07-28 Reopened by Alisdair. No longer solved by concepts. ]

[ Lillehammer: The first part is NAD, since "convertible" is well-defined in core. The second part is basically about pathological overloads. It's a minor problem but a real one. So leave open for now, hope we solve it as part of iterator redesign. ]

From comp.std.c++:

I note that given an input iterator a for type T, then *a only has to be "convertable to T", not actually of type T.

Firstly, I can't seem to find an exact definition of "convertable to T". While I assume it is the obvious definition (an implicit conversion), I can't find an exact definition. Is there one?

Slightly more worryingly, there doesn't seem to be any restriction on the this type, other than it is "convertable to T". Consider two input iterators a and b. I would personally assume that most people would expect *a==*b would perform T(*a)==T(*b), however it doesn't seem that the standard requires that, and that whatever type *a is (call it U) could have == defined on it with totally different symantics and still be a valid inputer iterator.

Is this a correct reading? When using input iterators should I write T(*a) all over the place to be sure that the object I'm using is the class I expect?

This is especially a nuisance for operations that are defined to be "convertible to bool". (This is probably allowed so that implementations could return say an int and avoid an unnecessary conversion. However all implementations I have seen simply return a bool anyway. Typical implementations of STL algorithms just write things like while(a!=b && *a!=0). But strictly speaking, there are lots of types that are convertible to T but that also overload the appropriate operators so this doesn't behave as expected.

If we want to make code like this legal (which most people seem to expect), then we'll need to tighten up what we mean by "convertible to T".