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

Subject: Re: [boost] [optional] generates unnessesary code for trivial types
From: Andrzej Krzemienski (akrzemi1_at_[hidden])
Date: 2012-02-13 08:28:30

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

Speaking for myself, I do not have a need for optional reference. I have
been using Boost.Optional for many years, I find it extremely useful; and I
never had a use case for optional reference. On the other hand, others seem
to be in need of optional references.Andrey said in this thread that that
he wants to use it. The only two motivating use cases that triggered the
addition of optional references (that I am aware of) is the interface of
Boost.Variant (see http://lists.boost.org/Archives/boost/2003/02/44585.php)
and the use case for Boost.Spirit (see
http://lists.boost.org/Archives/boost/2003/10/55584.php). I would be
reluctant to just discard these use cases. On the other hand, if they are
allowed, the controversy of assignment arises.

One thing to note is the requirement for optional references is not
motivated by optimization opportunities, but additional behavior.

> Side question: is streamablity going to be in your proposal?
It is not currently. The reason for that is that there is no clear way how
it should be implemented (a similar issue applies to pairs, tuples,
variant, any, etc...) See
http://lists.boost.org/Archives/boost/2005/03/81619.php for discussion. I
believe that the problem is with the streaming itself. For instance, should
streaming out and then streaming the result back in produce the same value?
Some people expect that, but even std::string could not provide this
behavior.

Regards,
&rzej