Boost logo

Boost :

Subject: Re: [boost] [optional] Safe optional
From: Vicente J. Botet Escriba (vicente.botet_at_[hidden])
Date: 2014-11-19 17:05:57

Le 19/11/14 21:46, Vladimir Batov a écrit :
> On 11/19/2014 05:58 PM, Vicente J. Botet Escriba wrote:
>> Le 19/11/14 01:55, Vladimir Batov a écrit :
>>> On 11/19/2014 10:52 AM, Vicente J. Botet Escriba wrote:
>>>> Le 18/11/14 22:35, Vladimir Batov a écrit :
>>>> ...
>>>>> 2. I find it troubling that you keep bringing "remove implicit
>>>>> conversion from T " up. That indicates that the property is close
>>>>> to the top of your "grievances" list. On my side, I find that
>>>>> implicit conversion essential for sane interactions of users with
>>>>> "optional". Back a while, when we were discussing "optional" (was
>>>>> it ISO forum?), I remember Fernando Cacciola expressing the same
>>>>> opinion (and as strongly). I'd greatly appreciate if you could
>>>>> please provide practical usage/deployment examples where implicit
>>>>> conversion from T causes a problem.
>>>> It is about the pre-conditions. Before doing a conversion you need
>>>> to ensure that there is a value. This give an if-the-else style
>>>> that doesn't scale when you have several optionals in the game.
>>> Hmm, aren't we talking about different conversions? I was referring
>>> to "T to optional<T>". I have the feeling that you are referring to
>>> "optional<T> to T". I've never been advocating the implicit latter.
>> You are right. I was referring to optional<T> to T conversions. The T
>> to optional<T> conversion suffer from overload resolution ambiguity.
>> void f(int);
>> void f(optional<int>);
>> f(1); // ambiguous.
> As Andrey already pointed out (while I was asleep :-) it is not
> ambiguous.
>> but this is a different problem.
> Andrey, I and GCC insist that there is not problem here. :-)
void f(long);
>> Removing the conversion will make the following code correct
>> f(1);
>> f(make_optional(1));
> Again, (1) the code is already correct as-is. (2) asking the library
> user to call "f(make_optional(1))" where he conceptually deals with
> "ints" is cruel and wrong. The user needs to to program and deal with
> his domains concepts ('int' in this particular case) not
> optional<int>. Logically, from the user perspectives, the no-int
> condition is not part of the range. It's special case. Technically,
> for implementation purposes, however, it is. That's where "optional"
> steps in and bridges the gap between logical/human view and
> implementation. Contorting the human view to cater for implementation
> has always been wrong.
My examples are not the best. Andrzej one in this thread is much more

   return ac.weight() > ac.max_weight();

The safe_optional would just not accept this expression. I understand
people that could prefer this security.
>> ...
>> For those that have not yet see the Seasoning talk from Seam Parent I
>> suggest you take a look at the no-raw-loops part The other are also
>> interesting, of course, but this part is really related to what we
>> are discussing.
>> I agree with you that in general people don't even know all the std
>> algorithms are there (and that they can create their own).
> I've been in s/w longer that I can remember and to be honest those
> std::for_each and the ilk do not grow on me... unless they provide
> *real* functionality (like sorting, etc.)... and I honestly tried to
> love them... The reason is simple -- readability. I jump back to the
> old code and immediately see/understand what it does. Lambdas *might*
> address that... Can't judge... C++0x compilers throughout.
I can understand you if you are using a C++98 compiler. The for_each
example has already been replaced by range-based for, but there is much
more than for_each.

do-notation result in code more readable. All we need in C++ is to add
some syntactical sugar to cover the common cases. operator await would
be a major step in this sens. await propagates the not-a-value cases,
and return converts explicitly to the result type. But the conversion
from T to M<T> is not implicit. We need some kind of make factory that
results in something that is implicitly convertible to M<T>.

what do you think of

   f( explicit 1 );

to state that we want an explicit conversion to a M<int>?


Boost list run by bdawes at, gregod at, cpdaniel at, john at