Convertible to T
Chris Jefferson

Created on 2004-09-16.00:00:00 last changed 60 months ago


Date: 2017-07-15.23:15:19

[ San Francisco: ]

Solved by N2758.

Date: 2017-07-15.23:15:19

[ 2017-07 Toronto Thurs Issue Prioritization ]

Priority 2; same as 2962.

Date: 2017-06-02.00:00:00

[ 2017-06-02 Issues Telecon ]

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

Marshall to research

Date: 2017-06-05.15:41:21

[ 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.

Date: 2010-10-21.18:28:33

[ 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.

Date: 2009-07-28.00:00:00

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

Date: 2010-10-21.18:28:33

[ 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. ]

Date: 2011-03-05.00:04:13

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 unnessary conversion. However all implementations I have seen simply return a bool anyway. Typical implemtations 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".

Date User Action Args
2017-07-15 23:15:19adminsetmessages: + msg9385
2017-06-05 15:41:21adminsetmessages: + msg9197
2017-06-05 15:41:21adminsetmessages: + msg9196
2017-06-05 15:41:21adminsetstatus: lewg -> open
2014-11-24 15:11:58adminsetstatus: nad future -> lewg
2010-10-21 18:28:33adminsetmessages: + msg2807
2010-10-21 18:28:33adminsetmessages: + msg2806
2010-10-21 18:28:33adminsetmessages: + msg2805
2010-10-21 18:28:33adminsetmessages: + msg2804
2004-09-16 00:00:00admincreate