Re: [boost] compact_optional -- prompting interest

Subject: Re: [boost] compact_optional -- prompting interest
From: Andrzej Krzemienski (akrzemi1_at_[hidden])
Date: 2015-09-28 04:05:43

2015-09-26 23:34 GMT+02:00 Andrey Semashev <andrey.semashev_at_[hidden]>:

> On Sat, Sep 26, 2015 at 7:52 PM, Andrzej Krzemienski <akrzemi1_at_[hidden]>
> wrote:
> > 2015-09-25 17:37 GMT+02:00 Andrey Semashev <andrey.semashev_at_[hidden]>:
> >>
> >> However, I'm not sure I agree with your rationale on the reduced
> interface
> >> and possibly the compact_optional naming.
> >>
> >> 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.
>
> It can, but I really don't see the reason for it. Can you give an
> example where operators defined for type T are not sensible to
> compact_optional<policy<T> >?
>

I am trying to avoid the problem Boost.Optional (and
std::experimental::optional) has, where it offers a mixed comparison
between T and optional<T>. It is described in this post:

https://akrzemi1.wordpress.com/2014/12/02/a-gotcha-with-optional/

Of course, because I provide no converting constructor, the mixed
comparisons are removed...

However, n this type I want be users to be very explicit about what they
want, and it is not that obvious that they want to order the special value
the same way as they would if they were using the raw type directly.

>
> >> 2. compact_optional does not provide direct assignment of the values of
> >> the stored type, requiring to manually construct a
> compact_optional-wrapped
> >> value. To me, this is too cumbersome to use while I don't see any wins
> from
> >> this restriction. Besides more typing, this essentially requires to use
> a
> >> typedef to declare and use the compact_optional variable.
> >
> > Are you proposing a member function like opt.store_raw_value(v); ?
>
> No, I was suggesting to allow assignment of values of type T (i.e.
> "opt = v;"). Having a named function like store_raw_value reduces the
> need in the typedef but the syntax should still be simpler.
>
> You may object that this allows the assignment to make the opt object
> empty (or null, or singular - not sure what terminology you prefer).
> This may seem counterintuitive at first glance, but only as long as
> you treat the type as another flavor of optional<>, which is incorrect
> and is one reason why the name should be changed. What
> compact_optional really is is just a wrapper that allows to easily
> distinguish a special value of the governed object from all other
> values, and in that light there's nothing wrong if assigning this
> special value to the wrapper makes it singular. Analogously, there's
> nothing wrong with assigning a nullptr to a pointer.
>

In a way, this would mean and implicit conversion from T to
compact_optional<T>. I do not want any kind of implicit conversion between
the two (because the two are something different). I could offer:

opt.raw_value() = some_T;

Regards,
&rzej