Re: [boost] compact_optional -- prompting interest

Subject: Re: [boost] compact_optional -- prompting interest
From: work (Vladimir.Batov_at_[hidden])
Date: 2015-09-25 18:45:35

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.

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).

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.

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.

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.

> ...
> 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.

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

V.