Boost logo

Boost :

Subject: Re: [boost] [optional] operator<(optional<T>, T) -- is it wrong?
From: Vladimir Batov (Vladimir.Batov_at_[hidden])
Date: 2014-11-27 18:12:49


On 11/28/2014 07:52 AM, Andrzej Krzemienski wrote:
> 2014-11-27 21:35 GMT+01:00 Vladimir Batov <Vladimir.Batov_at_[hidden]>
> :
>
>> On 11/28/2014 12:22 AM, Andrzej Krzemienski wrote:
>>
>>> ... Technically, the behavior of op<(optional<T>,T) is well-defined and
>>> consistent with the conceptual model of optional. However, every practical
>>> use case I have seen so far is a programmer bug.
>>>
>> I personally have to disagree with the statement... I find your readiness
>> to immediately promote T to optional<T> unreasonable.
>
> It is not *my* (human's) readiness to promote T to optional<T> everywhere.
> This is simply a consequence of providing the converting constructor. The
> message sent by declaring the converting constructor (the way I understand
> converting ctors) is that T can be used *everywhere* where optional<T> is
> required. Even in the places where someone may not like that.

OK, it's not your "human readiness" :-) to promote T to optional<T> but
it's your (as it appears to me) position that, if we allowed the
implicit constructor, then it's free to be jump in anywhere "it" wants
to. Given that clearly there are places where that T to optional<T>
promotion is questionable, you seem to favor banning it altogether. In
reality (or in human society) if 90% benefit from a particular rule,
law, etc., then it's allowed. Then, difficulties and bans are created
for the remaining 10% bending and mis-using the law.

>> If you have that functionality, it does not mean you apply it it left and
>> right and think it's the right thing to do.
> If there was no converting constructor but only some make_optional(), I
> would agree. But because we have the converting constructor, "the
> functionality" is automatically applied everywhere.

... And I am only advocating to disallow "the functionality to
automatically apply everywhere". Namely, where it's deemed not to be
beneficial to do so... without forcing 90% suffer for the design/concept
purity... but you seemingly resist that selective approach. I am sensing
that's a fairly strong and seemingly non-negotiable position of yours so
it's wise to simply acknowledge differences in our views. No drama.


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk