-----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Fernando Cacciola
I think that was an excellent analysis of the choices.
Well, if my analysis was correct, choice (2) is the only one that doesn't _force_ ALL generic code to follow the pattern above. Thus, in spite of the fact that it breaks the rule "do as T& does" (becasue it can't follow it completely), it is the least impacting choice.
What do you think?
(2) suits my personal use well because when I want something to be nullable I happen to want it to be rebindable too. From what I understand though, this is silently causing incorrect behavior in generic code. Also, it does seem to make sense to keep the concepts Rebindable and Nullable separate. I think the problems surrounding (3) rule out using it. (1) is pretty restrictive. The nice thing about its restrictiveness is that it will turn inappropriate uses into compile time errors instead runtime errors. If it does break existing code it won't do so silently. My only question is does it solve the problems that are currently being cause by (2)? BTW Fernando, I did a quick search of my code and found 991 mentions of boost::optional! Every couple of weeks I find another situation where it provides an elegant solution to a previously messy problem. I was originally pleased by optional's usefulness in communicating with other programmers but lately I've become even more excited about its ability to communicate intent to generic code. Thanks! Brock