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

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
participants (1)
-
Andrzej Krzemienski