Re: [Patch] First bits of the algo merge

[chris jefferson <caj at cs dot york dot ac dot uk>]

Howard Hinnant wrote:
> 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)?
>
Yep :) That would be me, similarly 485 (which is in my opinion the more
serious one, 484 is just "playing with stupid types", whereas 485 seems
to ask a more serious questions. Do you have to assign every output
iterator? can you do it in a stupid order? How far forward can you move
before assigning?)
> 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...
>
> 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.
>
Yup, I agree.
> 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. :-)
>
I'm not convinced it's lazy, I think returning bool should be mandated
unless someone can come up with "good reasons" to allow anything else.
Also I would also be tempted to say that any types which "get fed into
the standard library" must not overload &&, || or "," and just be done
with it :)

Chris
> -Howard
>