Re: [boost] [optional] Safe optional

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

   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>?

Vicente