Re: [boost] compact_optional -- prompting interest

Subject: Re: [boost] compact_optional -- prompting interest
From: Gonzalo BG (gonzalobg88_at_[hidden])
Date: 2015-09-29 03:11:16

Gavin Lambert wrote:
> On 28/09/2015 21:05, Andrzej Krzemienski wrote:
>>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.
>>[...]
>>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;
>
>This is still clunky; either an implicit conversion or simply an
additional assignment operator to permit the other syntax is better.

I am against all three options, since right now my code looks like this:

opt_t opt_val;
opt_val = opt_t{some_T};

which is not that bad. In particular:

- I don't use raw_value for assignment, I only use it for when I need
unwrapped access to the storage_type independently of the optional being
empty or not, e.g., to implement a hash function or for serialization.

- additional assignment operator/implicit conversion: this would make the
tags less useful, so I am against it since using tags extensively has made
my code better.

@Andrzej: Right now your implementation allows constructing a
compact_optional from the sentinel value, which results in an empty
compact_optional. What is the motivation for this?

In my fork I've disabled it for the following reasons:
- I'd rather use compact_optional's default constructor to explicitly state
that i'm constructing an empty optional, this made it easier to reason
about my code,
- the other constructors from value_type can then hint the compiler that
the compact_optional is not empty (but I did not profile so I don't know if
this has any impact at all).