Boost logo

Boost :

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. :-)

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