Re: [boost] [optional] generates unnessesary code for trivial types

Fernando Cacciola wrote:
> OTOH, this is not the only update that the library needs, so be patient.
I'd be willing to do the work.  I may not have to since Domagoj Saric has done most of the work and I just need to convince him to ditch the pointer.

> FYI I'm currently working closely with Andrzej Krzemienski on a std proposal which, among other things, involves the long awaited update to the Boost implementation.
Could you give a use case for optional<T&>.  When reading the doc about I completely understand the other use cases:
* return types
* parameters
* locals
* members
* expensive unnecessary default construction

We could be having the same conversation about optional<bool>.  Here the documentation is clear: it works as expected but is the user probably should be using tri-state.

We could optimize optional<bool> to store ~0 to indicate unset.  I personally don't think it's worth doing that, since use case is questionable.

As far as I can tell optional<T&> is a type which can be easily confused with optional<T>, but is really equivalent to T*.  It also allows for debates about the meaning of reassignment.

I'm not dead set against this optimization.  I'm just wondering if anyone will really benefit and if it's worth adding a specialization + tests.


Side question: is streamablity going to be in your proposal?

Chris