Re: [boost] compact_optional -- prompting interest

Subject: Re: [boost] compact_optional -- prompting interest
From: Domagoj Saric (domagoj.saric_at_[hidden])
Date: 2015-10-01 06:13:11

On 25.9.2015. 16:35, Andrzej Krzemienski wrote:
 > Hi Everyone,
 > 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.
 >
 > Compact optional T has (or can have) the same sizeof as T. It uses one
 > indicated value of T to represent the "empty" (or "singular") value. You
 > can declare it like this:
 >
 > compact_optional<evp_int<int, -1>> oi;
<...>
 > It is not meant to be an alternative to Boost.Optional: it targets a
 > different application space.

Hi Andrzej,

+1 @ the improvement (as just one of the many improvements and 'polishes' long 
overdue for boost::optional)
-1 @ making it a new/different class template

If the improvement/change does not prevent providing the same interface and 
semantics as optional while offering same-or-better efficiency - then it's just 
simply better.

IOW, I'm all for adding a new 'policies' template parameter (properly defaulted 
for backwards compatibility) to optional (or perhaps trait(s) classes instead of 
a new template parameter - w can debated that ;).
The one-size-fits-all shared_ptr and 
make-every-one-pay-for-everything-no-matter-how-fat-it-is iostreams, filesystem, 
Qt,... logic is IMNHO so C#/Java like and so 'unworthy' of C++...so can we 
please remove that mentality from optional before it gets into the standard?

As the discussions and (already implemented) proposals from a couple of years 
back show, eg.:
http://lists.boost.org/Archives/boost/2012/01/189857.php
http://lists.boost.org/Archives/boost/2009/10/156750.php
there are many other possible and needed improvements for optional and it is not 
nearly all about memory efficiency. There are many codegen issues, for example 
if I work with floats that must never be NaN, I'd want to wrap them in 
optional<float, NeverNaNPolicy> _without_ the compiler suddenly adding braindead 
branching in my code and passing the never-nan-floats through the stack (instead 
of in registers like 'raw' floats).

The approach with different class templates will actually cause uglier user code 
in the long run (as opposed to a relatively minor _one_time_ hurdle in only some 
projects that would be broken by a new defaulted parameter) - we'll end up with 
projects that use optional, pink_optional, compact_optional, smelly_optional and 
hal9000_optional... with someone having to track and document where and why each 
of those is used.

In addition, the different class templates and/or explicit specializations 
approaches either require either:
- duplication (of the shared optional interface and functionality that 
optional-like classes must have)
- a private base/impl class w/ policies which the public 'different class 
templates' and/or 'explicit optional specializations' can reuse.

If duplication is 'almost always evil', 'all I'm saying' is make the 'private 
base/impl class w/ policies' the public boost/std::optional proper...

C++ >In The Kernel< Now!

-- 
Domagoj Saric
Software Architect
www.LittleEndian.com