From: Joel de Guzman (joel_at_[hidden])
Date: 2005-10-11 18:00:50
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