Reece Dunn wrote:
Fernando Cacciola wrote:
Sam Partington wrote:
[...]
Why not use partial specialization so that optional< T > has the semantic sugar, but optional< T & > does not? Or is this already the case?
I'm not too fond of template classes that support different interfaces according to the properties of the template parameters. That just doesn't play along with generic programming where the type you optionalize can or cannot be a reference. Think of vector<bool> for instance. I rather keep looking for a consistent solution.
A related note about the use of operator *
You said that, even for optional<T&>, it is clear that this:
*o = i;
is UB if 'o' is uninitialized. And so there is no problem defining that assignment as really just the assignment of the underlying type, which in the case of optional<T&> doesn't rebind.
Now I wonder, if instead of operator*, we used value() (or whatever), would it be just as clear?
// Nullable interface
*o = rb ; // assing 'b' to 'a' o = none ; // releases 'a' *o = rc ; // !!! UB !!! Cleary IMO
// Container interface
o.value() = rb ; // assing 'b' to 'a' o.reset() ; // releases 'a' o.value() = rc ; // !!! Still UB !!! ¿But cleary enough?
I personally prefer the nullable interface as it is more intuitive w.r.t. smart pointer usage. o.value() = b reads to me like value() is returning a (temporary) return value, then you are assigning rb to that.
Me too!
Q: If o == none, does *o = foo throw? (I am not familiar with optional<>)
Yes.. Although strictly speaking is Undefined Behaviour. Depending on the compilation options and your boost setup that can throw or core dump.
optional<bool> side, is it posible to provide a specialization for it that doesn't break the optional interface, but still provides the functionality that is wanted from an optional<bool> type as discussed elsewhere?
Is possible, but I don't like it for the reasons expressed before. Best -- Fernando Cacciola SciSoft http://fcacciola.50webs.com/