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