Re: [boost] compact_optional -- prompting interest

Subject: Re: [boost] compact_optional -- prompting interest
From: Andrzej Krzemienski (akrzemi1_at_[hidden])
Date: 2015-09-26 12:31:18

2015-09-26 0:45 GMT+02:00 work <Vladimir.Batov_at_[hidden]>:

> Andrzej,
>
> On 2015-09-26 00:35, Andrzej Krzemienski wrote:
>
>>
>> I would like to inquire if there would be an interest in Boost in another
>> library for storing optional objects, but working under different design
>> goals.
>>
>> ... It uses one
>> indicated value of T to represent the "empty" (or "singular") value.
>>
>
> In other words, your proposed design is intrusive as it carves something
> from T for its own purposes.
>

Indeed, I have also considered name "intrusive_optional".

> 1) IMO non-intrusive design is by far preferred even if it comes with
> extra-cost (shared_ptr might serve as an example). It's not to say
> intrusive design has no place. It does... but seems niche as opposed to a
> generic solution... which Boost seems to be positioning itself (IMO).
>

Indeed; also compact_optional library comes with the advice that you should
try boost::optional first, and only if you have performance problems with
it, should you try to use compact_optional instead.

> 2) Obviously that technique has been used for a long time and it's not
> immediately obvious to me if the extra interface adds much real value or
> most importantly clarity/safety. To me having allocated -1 or std::max<int>
> (or whatever) to represent no-value, i.e. "no-int" feels hackish. If, as a
> developer, I advertise "int" to the user, IMO the user is entitled to
> expect the full "int" range available. If, as a developer, I do not provide
> the full range, the proper way (IMO) would be to introduce a new explicit
> type to represent the supported subset (via enum or proper sensibly-named
> type -- time, speed, temperature, etc.) In other words, if I cannot provide
> "int", I should not be saying that I do.
>

Ok, I think I see where you are coming from. This is an interesting topic
in itself; but for now I only stick to advertising compact_optional. Using
the words from your description above, when you have decided to use the
hack with "magic value", you can use compact_optional to make this explicit
and visible to the type-system: now "int" and "int with magic value" are
never confused.

>
> 3) I am trying to see if compact_optional might fit in my projects and
> fail. When in memory, I by far prefer boost::optional for its orthogonality
> -- it adds functionality without taking anything from T.
>

And more: boost::optional does not force you to take the time and consider
and declare how you want to store the no-value.

>
> I do have the need to be real frugal when I store data to the disk. But
> for that purpose I have to be far more economical and size-specific than
> compact_optional.
>

Indeed. We could say that compact_optional gives you a "generic
optimization": it is a fairly generic and mechanical optimization over
boost::optional, but to maximally optimize your particular case, you need
to do it manually.

>
> ...
>> It is not meant to be an alternative to Boost.Optional: it targets a
>> different application space.
>>
>
> I am not sure I immediately agree with you positioning your proposed
> "compact_optional" as no competitor to the established "optional". After
> all, your proposed "compact_optional" tries to address the same problem of
> representing no-value. You even call it similarly. Surely, it for a reason.
>

If not anything else, this often came out as an extension request to
boost::optional and std::experimental::optional. My idea of the two
libraries is this:

When you design a new data structure, you just use boost::optional to
represent optional values. Whet it never causes performance issues, you
leave it at that.

Another situation is where you already encode a magic value in your type
int, you consider changing it to boost::optional, but are concerned about
adding potential run-time overhead. Your concerns may be misplaced, but
only having a concern (valid or not) is often enough to reject a safer
library solution (boost::optional). compact_optional does not give you this
concerns: it gives you a different trade-off between type-safety and
"performance concerns".

>
> Having said that I can easily be wrong and I am prepared to be convinced
> otherwise.
>
> V.

Reards,
&rzej