Re: [boost] [optional] Safe optional

Subject: Re: [boost] [optional] Safe optional
From: Vladimir Batov (Vladimir.Batov_at_[hidden])
Date: 2014-11-20 17:48:57

On 11/21/2014 09:13 AM, Andrzej Krzemienski wrote:
> 2014-11-20 21:57 GMT+01:00 Vladimir Batov <Vladimir.Batov_at_[hidden]>
>
>> ... Does it make sense?
> It does. You are also correct to observe that we have started talking more
> about feelings than anything that can be objectively asserted.

:-) Actually it was *me* talking about "feelings"... and it was only a 
figure of speech to highlight the fact that I am open for discussion 
rather that heading for confrontation. The behavior I am advocating (or 
have feelings for ;-) is fairly straightforward IMO (of course). I can 
sum them up as follows.

1) When we are bringing T into the optional<T> land, we apply implicit 
constructor. For example, we provide T to a function taking optional<T>. 
Here, the direction of the conversion is unambiguous. Namely, T to 
optional<T>. So, we apply it.

2) When the direction of conversion is not as clear, we refuse applying 
it and leave it to the user. op<(T, optional<T>) would be one such example.

> I am forced
> to admit I might be tempted to apply a too simplistic view. But that is
> still too little for me to get convinced that we should allow the
> converting constructor and poison the mixed operator less at the same time.

Well, trying to advocate an idea is always an up-hill battle. 
Unfortunately, it's all I have. If it does not convince you, so be it. I 
just thought that solution would fix many potential mis-uses of 
"optional" without any sacrifice in functionality of forking off.

> I agree that there is no solution here that would be considered
> satisfactory by everyone, so we are forced to select the least of two
> evils, and it seams that there is no objective way of even measuring the
> two evils.

I am not sure I agree. What I find attractive in "my" (for simplicity 
sake) suggestion is that it provides explicitness (i.e. safety) when we 
need it *without* sacrificing any existing functionality or interface. 
I.e. win-win situation. So to speak,
wolves are fed and the sheep are safe. :-)

> The usage of converting constructor in optional only shows to me that we
> have not established a good criteria for telling when having a converting
> constructor is a good idea. I always used to think that if only you are not
> loosing any information, it is safe. But in the case of optional I can see
> that even then it can have some negative consequences. Perhaps it is the
> way the language is designed that is wrong: that you either allow this
> conversion in every possible situation or never at all.

Oh, c'mon. Cheer up. Things are not as gloomy, are they. :-) Here the 
subtlety (IMO) lies in how reasonable it is to add information. Namely, 
as I indicated, if we bring T into the optional<T> fold, then we apply  
optional<T> rules to T, i.e. apply t to optional<T> conversion. Say, we 
have a mandarin and an orange. When we bring the mandarin to an orange 
factory, then mandarin-to-orange "conversion" is applied and for all 
purposes mandarin is a "small orange". Outside the factory, when we 
compare mandarin to orange, it is not immediately clear what should be 
treated as what. If we apply mandarin-to-orange "conversion", then it'll 
be "small orange vs. big orange". If instead we apply orange-to-mandarin 
"conversion", then it'll be "sweet mandarin vs. sour mandarin". Given 
the library writer does not know, which it is, we ban it. Still not 
convinced? I've spent all munition I had. :-)