Re: [boost] compact_optional -- prompting interest

Subject: Re: [boost] compact_optional -- prompting interest
From: Seth (bugs_at_[hidden])
Date: 2015-09-26 15:04:41

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)