Fernando Cacciola wrote:
Joel de Guzman wrote:
Howard Hinnant wrote:
I believe there was specific concern about reference rebinding under optional<T&>. There were also several comments that went like: I use optional all the time (gives use case), but I've never needed to use it with reference types.
[...]
You might explore a interface here on boost which did not have the pointer interface, and which dropped reference support. Then perhaps submit a follow on paper reflecting that experience. Said paper may either modify your current proposal, or more fully support it.
I use optional reference but I do not like the way rebinding works. I still insist that it follow the way boost::tuple does it. IMO, the same way with tie, when you need it, you'll really need it. I think it was I who requested for optional references, so let me present my use case:
In Spirit, a parser may return an attribute. This attribute should only be constructed on a successful match. Thus, optional<T>. A symbol table is a parser in Spirit. Each symbol has a corresponding data slot. On a successful match, the attribute returned is a reference to the data slot. Thus optional<T&>.
Ya, if you use optional<T> generically, chances are T is really a reference, so you do want it to support references. And I don't think we should drop that support because of the rebinding issue since I don't see it as much of an issue.. IMO, is about wrapping the mind around the nature of an "optional reference"... once you do that, the current binding rules just comes naturally IMO.
The nature of an optional object is that it can be absent... and when an optional reference is absent, there is not much of a choice about what to do: you just have to bind to the rvalue.
Since this expression:
opt = ref ;
cannot but to bind 'opt' to 'ref' if 'opt' happens to be absent, then IMO it just better do that _always_, no matter if 'opt' is absent or not. The other choice of semantic would be inconsistent and depending on the previous state of 'opt'.
Again, my main objection is this rebinding thing. I don't care so much about the "pointer interface". It's easy to simply ignore it. My main problem is with this rebinding thing. It's counter intuitive and does not follow the tuple<T&> NOR the variant<T&, nil> sementics. In Spirit-2, I will be needing all three as part of client interface of semantic actions: a >> b --> tuple<A, B> a | b --> variant<A, B> !a --> optional<A> It just so happens that !a is a synonym for: a | eps --> variant<A, nil> !!! DANG !!! !a and a | eps behave differently!!! My opinion is very strong on this. THIS BEHAVIOR IS WRONG! No to special cases. Regards, -- Joel de Guzman http://www.boost-consulting.com http://spirit.sf.net