> Thanks to the clear arguments made by the reviewers, I see the picture a lot > more clear now. > Specially the fact that optional<> is itself a container, or perhaps, a > union of T and nil_t. > But your previous post were you developed those concepts were very helpful > as an argument to keep the pointer-like interface.
I hope you mean "instead of the container interface." I don't have a problem with the pointer-like interface, it makes sense to me...I prefer the value based one, but I understand that is just personal preference. However, I definately don't think we need to mix the two as that would just be confusing. For what its worth, I prefer the union concept. Union semantics clearly state that you can have either or (i.e., not both). Furthermore, the fact that Joel identified optional<> as a specialization of variant<> reinforces my belief that a union based concept would be easier to explain. When you start explaining this in terms of pointers people immediately start assuming memory management and aliasing; however, optional<> is not about those. optional<> in my opinion is clearly a union of T and nil_t. Furthermore, the fact that people have, in the past, used pointers for optional values does not necesarrily mean that is the right vision to propogate. Pointers were the easiest way of providing an optional value; it's not that they were comprehensible, or even that they made a great mental model, just that they were convienient. You have a chance now to redesign our notion of what constitutes an optional value--to make it comprehensible and convienient. Holding on to history for history's sake is not always the best option. Tanton _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
