Re: [Patch] First bits of the algo merge

[Howard Hinnant <hhinnant at apple dot com>]

On Dec 15, 2005, at 12:41 PM, chris jefferson wrote:

> Howard Hinnant wrote:
> > Such an iterator would only qualify as an input iterator, but
> > otherwise I think would be conforming, reference 24.1.1p2, table row:
> >
> > *a      convertible to T
> The issue of exactly what convertible to T should cover is library  
> issue
> 484, it looks like the whole issue is "up in the air" and there is say
> exactly what is supposed to work (in particular, is it "our job" to
> force conversion to the value_type or not), and what isn't, is  
> supposed
> to be handled as part of the iterator redesign.
>
>
> Chris

<nod>  I assume you are the same Chris as the submitter of this dr  
(if you like I can add your last name to this and any other dr's if  
that's the case)?

I tend to agree with your latter statement:

> I am personally tempted to say that any iterator where "*a == *b"
> doesn't work is probably so broken we shouldn't be going to the effort
> to force it to work...

Indeed that was my motivation for adding METHOD_C, which simply does  
"*a == *b".  Which you inspired with your earlier post:

> While making this work could very well be a reasonable goal, I notice
> that if I replace the calls to equal with std::equal, defined in the
> obvious way:
>
> template<typename _InputIterator1, typename _InputIterator2>
>     inline bool
>     equal(_InputIterator1 __first1, _InputIterator1 __last1,
>           _InputIterator2 __first2)
>     {
>       for (; __first1 != __last1; ++__first1, ++__first2)
>         if (!(*__first1 == *__first2))
>           return false;
>       return true;
>     }
>
> Then this proxy iterator doesn't work, so we aren't breaking anything
> that worked before...

Imho, it is the gold standard by which our efforts must be measured.   
If METHOD_C allows it, we probably should too.  If METHOD_C allows  
it, and it is conforming, then I think we have no choice but to allow  
it.

It is the second part of 484 that the lwg found most alarming:

> while(a!=b && *a!=0)

I.e., what happens with operator== (perhaps as the proxy defines it)  
doesn't return bool (only convertible to bool)?  This is also a  
concern apart from proxies, or even apart from iterators.  I think  
the basic question from the second part of 484 is:

Should we mandate that overloaded logical operators return bool?  If  
not, how much leeway do we give such operators?

The lazy part of me just wants to mandate returning bool. :-)

-Howard