[optional] from_optional

Hi, There is a common need of getting a value from an optional with possibility to define a default value in case of the optional is uninitialized. I suggest two alternatives: optional<int> o; int i = o.get(123); // a meber function get with an additional parameter int j = from_optional(o, 123); // a free function Both alternatives can be implemented simultaneously. What do you think about it? Regards, Vaclav

On 3/12/06, Václav Veselý <vaclav.vesely@email.cz> wrote:
There is a common need of getting a value from an optional with possibility to define a default value in case of the optional is uninitialized. I suggest two alternatives:
optional<int> o; int i = o.get(123); // a meber function get with an additional parameter int j = from_optional(o, 123); // a free function
Both alternatives can be implemented simultaneously.
Hello, Is there any reason why you cannot do: optional<int> o; int i = o ? *o : 123; Regards, Mikael

On Sunday 12 March 2006 11:38, Václav Veselý wrote:
There is a common need of getting a value from an optional with possibility to define a default value in case of the optional is uninitialized. I suggest two alternatives:
optional<int> o; int i = o.get(123); // a meber function get with an additional parameter int j = from_optional(o, 123); // a free function
Both alternatives can be implemented simultaneously.
What do you think about it?
I don't like the first one, it's just not intuitive enough. With the second one, same problem though maybe that's just the name. Also, if there is a sensible default, there is no need for optional<> anyways. Also, they don't provide much advantage to the ternary operator int i = o ? *o : 123; just that you only have one 'o' in there instead of two. However, I just had a crazy idea, how about overloading an operator for them: int i = o | 123; int j = o / 456; int k = *(o|123); or maybe putting this choice into the name like int l = o.get_value_or(012); Biggest problem with the operator approach is that it might obfuscate things in that it is not immediately clear whether the state of the optional or the value of the optional is used. Also, I can see many optionals being used in boolean operations (e.g. with ||) so it might be a bad idea overloading operator|, too.... Just curious, does anybody know of a lib that uses operator- for string concatenation? Uli

Ulrich Eckhardt wrote:
On Sunday 12 March 2006 11:38, Václav Veselý wrote:
There is a common need of getting a value from an optional with possibility to define a default value in case of the optional is uninitialized. I suggest two alternatives:
optional<int> o; int i = o.get(123); // a meber function get with an additional parameter int j = from_optional(o, 123); // a free function
I don't like the first one, it's just not intuitive enough.
Maybe better selected name could be more intuitive.
Also, if there is a sensible default, there is no need for optional<> anyways.
I don't think so. Library functions can return optionals and it depends on the user of library if there is a default value and what is is.
Also, they don't provide much advantage to the ternary operator int i = o ? *o : 123; just that you only have one 'o' in there instead of two.
There are two points: 1) As Sebastian Redl in another post said, o can be returned from function. 2) I think, that my proposal is more readable and elegant.
However, I just had a crazy idea, how about overloading an operator for them: int i = o | 123; int j = o / 456; int k = *(o|123);
I don't like this much. I prefer descriptive function names to weirdly overloaded operators.
or maybe putting this choice into the name like int l = o.get_value_or(012);
I would be satisfied with any reasonable name. Except of replacing missing value with default there is are more strategies of handling missing values. For example Property Tree library (which is scheduled for review) has four (!) methods for getting value with for ways of handle the case of missing value. That strategies are throwing an exception, return default value, return optional and get the value in an out parameter and returning only the flag. I think, that all these strategies should be solved in optional library. The method names could be: val = opt.get_or_exception() val = opt.get_or_default(123) tie(flag, val) = opt.get_tuple() flag = opt.get_xxx(val) // reference to a variable I'm not sure with the neme of the last version. Regards, Vaclav

On Sunday 12 March 2006 11:38, Václav Veselý wrote:
There is a common need of getting a value from an optional with
Ulrich Eckhardt wrote: possibility to
define a default value in case of the optional is uninitialized. I suggest two alternatives:
optional<int> o; int i = o.get(123); // a meber function get with an additional parameter int j = from_optional(o, 123); // a free function
I don't like the first one, it's just not intuitive enough.
Maybe better selected name could be more intuitive.
Also, if there is a sensible default, there is no need for optional<> anyways.
I don't think so. Library functions can return optionals and it depends on the user of library if there is a default value and what is is.
Also, they don't provide much advantage to the ternary operator int i = o ? *o : 123; just that you only have one 'o' in there instead of two.
There are two points: 1) As Sebastian Redl in another post said, o can be returned from function. 2) I think, that my proposal is more readable and elegant.
However, I just had a crazy idea, how about overloading an operator for them: int i = o | 123; int j = o / 456; int k = *(o|123);
I don't like this much. I prefer descriptive function names to weirdly overloaded operators.
or maybe putting this choice into the name like int l = o.get_value_or(012);
I would be satisfied with any other reasonable name. Except of replacing missing value with default there there are more strategies. For example Property Tree library (which is scheduled for review) has four (!) methods for getting value with for ways of handle the case of missing value. That strategies are throwing an exception, return default value, return optional and get the value in an out parameter and returning only the flag. I think, that all these strategies should be solved in optional library. The method names could be: val = opt.get_or_exception() val = opt.get_or_default(123) tie(flag, val) = opt.get_tuple() flag = opt.get_xxx(val) // reference to a variable I'm not sure with the neme of the last version. Regards, Vaclav

"Ulrich Eckhardt" wrote:
optional<int> o; int i = o.get(123); // a meber function get with an additional parameter int j = from_optional(o, 123); // a free function
Also, they don't provide much advantage to the ternary operator int i = o ? *o : 123; optional<int> foo () { ... expensive, returns empty optional on error .... } optional<int result = from_optional(foo(), 123); The names could be safe_get() and optional_with_default(). /Pavel

Am Sonntag, den 12.03.2006, 11:38 +0100 schrieb Václav Veselý:
Hi,
There is a common need of getting a value from an optional with possibility to define a default value in case of the optional is uninitialized. I suggest two alternatives:
I recently had this need too. Modern C++ also means clean and nice-looking code, IMHO. So we need this! I am really posting only to this relatively old thread because I find the need real and stumbled upon it very recently.
optional<int> o; int i = o.get(123); // a meber function get with an additional parameter int j = from_optional(o, 123); // a free function
Both alternatives can be implemented simultaneously.
What do you think about it?
I'd prefer a member function because I also don't like free functions like "get". I'd rather write x.template foo. A nice method name would be get_with_default. The alternative get_or_default is hardly readable. Just with_default would be fine for me, too.
Regards, Vaclav
Aristid
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
participants (7)
-
Aristid Breitkreuz
-
Mikael Lind
-
Pavel Vozenilek
-
Sebastian Redl
-
Ulrich Eckhardt
-
Vaclav Vesely
-
Václav Veselý