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:55:19

> > I am
> > thinking of disabling the assignment not because I think it does not
belong
> > to references, but because there are two ways of implementing it, and
> > implementing it either way would surprise a different group of
> > programmers.
> > And this would be a "run-time surprise". Instead my choice (not
necessarily
> > the best one) is to provide a "compile-time surprise".
>
> If value semantics are achievable for this kind of optional, I think
> it's better to supply that and let the people who don't expect value
> semantics be surprised at runtime.

It is very difficult to provide a non-surprising/non-controversial
behavior. While I am not happy with my solution, I would also have concerns
about "run-time surprise" because:

First, there are two ways of implementing optional reference assignment
(rebinding or not rebinding) and it seams (from the past discussions in
this group) that either is equally counter-intuitive, and it is not clear
which one to choose. It would have to be an absolutely arbitrary choice.
People are strongly convinced about their views and it is not possible to
come up with a reasonable compromise. In fact it is the optional reference
assignment that prevented the addition of Optional to ISO C++ the first
time (http://lists.boost.org/Archives/boost/2005/10/95120.php).

Second, it is difficult to say about value semantics here. References
themselves are not really value semantic (at least according to my
understanding of the term): they have shallow copy constructor and deep
copy assignment. Even if it is disputable for native references, it is more
so for optional references, which removes the "special" aspects of
references, like extending the life-time of a temporary, reference
semantics, or no-storage requirement. We would be building value semantics
on a non-value-semantic type. Or in other words, I am concerned that we
would only be providing "value-semantics syntax" but not "value-semantics
semantics". But we would violate the axioms of value semantic types (like
the "separation of the value").

Regards,
&rzej