On 09/26/2015 06:52 PM, Andrzej Krzemienski wrote:
1. You chose not to provide relational operators for compact_optional
because you don't know how to order 'empty' values. I think you don't have to make that decision and simply forward the call to the underlying type. I mean, you always have the stored object constructed in some state and as long as it implements operators you can always use them.
So this is a trade-off between convenience/expressiveness and the potential to detect unintended semantics at compile-time. If there is sufficient argumentation in favor of adding them, I can always do it. As Rob says, this can also be encoded in the policy.
I'm in favour of the checking and explicit conversions. After all, otherwise one could literally use the underlying type with more convenience and the same level of safety. On 09/26/2015 06:52 PM, Andrzej Krzemienski wrote:
4. Regarding compact_optional naming. While the class can be used for
similar purpose as optional, its interface and behavior are significantly different. Perhaps a different name would be better to avoid confusion (e.g. nullable<>).
I agree with Andrzej; nullable<> is taken and means different things. How about 'signaling_value<>' . Yes `singular` is a good word but I don't immediately see how to synthesize a clear name for the type with it.
(Maybe discontinuous<>? Well. That is much broader again)