Seungbeom Kim wrote: >>> Is there, or will be, anything equivalent to boost::optional in STL? > I expect 'optional' to gain much wider use once it's > standardized; it enables a very useful and natural idiom of
> optional<Ret> function(Args...); > if (optional<Ret> r = function(args...)) { > // use *r > } > else { > // error > }
I can see why you would want this in the standard, but the syntax is definitely not what I would call "natural." optional<Ret> certainly looks like a smart-pointer, but IIUC, it does not have reference semantics; e.g., it performs deep copy. When I see something being used as a pointer, I don't want to have to shift my mind sideways to remember that it behaves completely differently. This looks like auto_ptr all over again. I'm not saying it isn't useful, but could we please use different syntax? Instead of overloading the dereference operator, for example, a value() member function would be less confusing.
Jeff Schwab wrote: > Seungbeom Kim wrote: >> I expect 'optional' to gain much wider use once it's >> standardized; it enables a very useful and natural idiom of
>> optional<Ret> function(Args...); >> if (optional<Ret> r = function(args...)) { >> // use *r >> } >> else { >> // error >> }
Just for the record, this is IMHO a bad example. If something is an error, not just one possible state, the function already should have thrown an exception. Returning an optional is useless then.
> I can see why you would want this in the standard, but the syntax is > definitely not what I would call "natural." optional<Ret> certainly > looks like a smart-pointer, but IIUC, it does not have reference > semantics; e.g., it performs deep copy.
...unless the value is moved instead of copied.
> When I see something being used as a pointer, I don't want to have to > shift my mind sideways to remember that it behaves completely > differently. This looks like auto_ptr all over again. I'm not saying > it isn't useful, but could we please use different syntax? Instead of > overloading the dereference operator, for example, a value() member > function would be less confusing.
Boost.Optional is a container for at most one element. It has an operator* to retrieve or operator-> to access the content. It can be used in a boolean expression, which yields true if it has an element. I shifted my mind in a way that operators * and -> only mean some kind of access through a handle object, regardless of where the referenced object lives. This more abstract view on those fits both pointers, smart pointers and various handle types.
With this mindset, I personally can live well with the syntax. For all others, there is the get() function that does what you want.
>>>> Is there, or will be, anything equivalent to boost::optional in STL?
>> I expect 'optional' to gain much wider use once it's >> standardized; it enables a very useful and natural idiom of
>> optional<Ret> function(Args...); >> if (optional<Ret> r = function(args...)) { >> // use *r >> } >> else { >> // error >> }
> I can see why you would want this in the standard, but the syntax is > definitely not what I would call "natural." optional<Ret> certainly > looks like a smart-pointer, but IIUC, it does not have reference > semantics; e.g., it performs deep copy. When I see something being used > as a pointer, I don't want to have to shift my mind sideways to remember > that it behaves completely differently. This looks like auto_ptr all
As far as I understood optional is intended to combine the pointer feature of having a null value with automatic storage (no heap twiddling). So I find the pointer syntax OK.
> over again. I'm not saying it isn't useful, but could we please use > different syntax? Instead of overloading the dereference operator, for > example, a value() member function would be less confusing.
There is the member function get() for those who prefer it.
Ulrich Eckhardt wrote: > Jeff Schwab wrote: >> Seungbeom Kim wrote: >>> I expect 'optional' to gain much wider use once it's >>> standardized; it enables a very useful and natural idiom of
>>> optional<Ret> function(Args...); >>> if (optional<Ret> r = function(args...)) { >>> // use *r >>> } >>> else { >>> // error >>> }
> Just for the record, this is IMHO a bad example. If something is an error, > not just one possible state, the function already should have thrown an > exception. Returning an optional is useless then.
There are "errors" (with quotes) that are not that "exceptional", as when you would just return a null pointer. And we may not have such a sentinel value for non-pointer types.
>>>> I expect 'optional' to gain much wider use once it's >>>> standardized; it enables a very useful and natural idiom of
>>>> optional<Ret> function(Args...); >>>> if (optional<Ret> r = function(args...)) { >>>> // use *r >>>> } >>>> else { >>>> // error >>>> }
>> Just for the record, this is IMHO a bad example. If something is an >> error, >> not just one possible state, the function already should have thrown an >> exception. Returning an optional is useless then.
> There are "errors" (with quotes) that are not that "exceptional", > as when you would just return a null pointer. And we may not have > such a sentinel value for non-pointer types.
As for me, that work a lot with databases, I use the null value as "missing" value. It's not an error. I want to use Optional so I don't have to allocate an int on the heap just to be able to get a pointer that can have a null (missing) value.
|
