I have a question though. Why prohibit opt = opt assignment? It looks quite safe and has a fairly obvious behavior. If I have an optional reference as a member of my class, the lack of assignment in optional would force me to define a custom assignment operator for my class. This seems to be an unnecessary requirement. Also, in the source code I dealt with I often saw people writing something like opt = optional<T>() to clear the value. This would break with references for no apparent reason.
First, let me show why opt = nval; is controversial. Current semantics for boost::optional<T&> is to rebind on assignment, which means that in the following code: int i = 1; int j = 2; optional<int&> oi = i; oi = j; The effect of this program is that i remains 1, j remains 2 and oi holds a reference to j. This is surprising to those that think of optional as delayed initialization. I lean towards disabling opt = opt because it is very similar to opt = nval; int i = 1; int j = 2; optional<int&> oi = i; optional<int&> oj = j; i = j; The effect here is that i remains 1, j remains 2 and oi and oj both hold a reference to j. You may find it less surprising but if you think of optional reference as a regular reference that is initialized a bit later, the behavior is not what you would expect. Note that if you store a normal reference to int as class member, you already have to write your assignment yourself. changing a normal reference to an optional reference should not come as something irregular.