On 11/21/2014 09:13 AM, Andrzej Krzemienski wrote:
2014-11-20 21:57 GMT+01:00 Vladimir Batov
... 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. :-)