Re: [boost] Re: Re: [optional] Reference assignment

From: Joel de Guzman (joel_at_[hidden])
Date: 2003-11-02 21:02:07

Fernando Cacciola <fernando_cacciola_at_[hidden]> wrote:

> I'm being inclined to prefer your proposed semantics but, incidentally, in
> spite of your use case which AFAICT simply reveals that you don't want to
> use the '*' syntax, but doesn't show a 'requirement' for true reference
> semantics.
> That is, as Brian says, you can have the semantics you want if you stick to
> the '*' syntax.
> This is not to say that there are no 'conceptual' reasons to prefer true
> reference semantics, however.

I see now that Brian has a point. Please see my other post.

> By studing your use case I wondered why wouldn't you use the '*' syntax,
> which I recommended from the beginning.
> In fact, your example is actually setting a very good case in favor of '*',
> let me explain:
> If the lhs is uninitialized then the assignment is undefined w.r.t true
> reference semantics. This is in fact exactly the same as trying to access
> (read) the value of an uninitialized optional.
>> From the beginning I wanted a special syntax to add lexical context to the
> operations that may be undefined when uninitialized optionals were involved.
> Currently, you _need_ to use '*' to access the optional value, and, if true
> reference semantics are to be used, then assignment is effectively accesing
> this value, so requiring '*' also for assignment looks right to me.

Right. I seem to prefer o.get() now which also gives me what I need.

> However, complains about the '*' syntax drawn me to assume that assignment
> was always well defined so I dropped the '*' as a requirement for
> assignment. But true reference semantics are actually breaking the
> assumption, leaving a question open: what to do if assignment cannot happen
> because the lhs optional<> is uninitialized? I realized now that if I had
> sticked to the '*', the question would have the same simple answer as the
> case: opt->assign(val) when opt is uninitialized: the behaviour is
> undefined.

Yes. Brian was right all along.

> Unfortunately, the current syntax options allows you to write either
> "*opt=val" or "opt=val", but, by the current design, both operations must be
> equivalent.

Oh, yes. That was exactly what I thought of on the way to our weekend vacation.

> This last observation settles the matter of assignment semantics AFAIC,
> which brings me back to the question I posted in this thread.

I think now that the real focus of our inquisition (:-) should be optional's 
assignment from T interface. Please see my other post. Anyway, regardless
of the final verdict (and you have the final say of course), I can live with
whatever semantics you decide on.

Regards and many thanks!

-- 
Joel de Guzman
http://www.boost-consulting.com
http://spirit.sf.net