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. :-)
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.
I really think that these make_ factories make the code much more readable.
let see how optional, any, expected default conversion work
void f(int); void f(optional<int>); void f(expected<int>); void f(any);
My current focus is "optional" and on that level "void f(int)" conveys what it does.
...
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.