Re: [boost] Report from Mont Tremblant C++ Committee meeting

From: Fernando Cacciola (fernando_cacciola_at_[hidden])
Date: 2005-10-17 16:14:10

Jaakko Jarvi wrote:
> [...]
>> I don't see what nullability per-se has to do with this discussion.
>>
>
> I agree with Ian and Joel.
> I don't see that nullability should be the decisive characteristic.
>
This is an excrept from the std proposal:

http://fcacciola.50webs.com/n1878.htm

>>>>>>>>>
Optional references rebind when assigned, that is:

int  a = 123 ;
int& ra = a ; // ra is bound to a
optional<int&> ora = ra ; // ora is bound to a
int b = 456 ;
int& rb = b ;
ora = rb ; // ora is re-bound to rb.

This is in sharp contrast with normal C++ references.

This decision was made to allow the definition of assignment to be 
independent of the prior initialization state of the lvalue. If the lvalue 
optional reference is uninitialized before the assignment there is no choice 
but to rebind.

int  a = 123 ;
int& ra = a ; // ra is bound to a
optional<int&> ora = ra ; // ora is bound to a
int b = 456 ;
int& rb = b ;
ora = nullptr ; // explicitly reset to uninitialized to make the point even 
more clear.
ora = rb ; // ora MUST bind to rb, there is no choice here.

Assignment to an initialized optional reference could be made to assign the 
referenced value, following the behavior of normal C++ references, but then 
the semantics of assignment would depend on the prior initialization state 
of the lvalue. The decision, albeit arbitrary, is to rebind."
<<<<<<<<<<<<<<

You still can't see what nullability has to do with the choice?

> Much more so optional is defined by:
>
>   In the case that optional holds a value, it should work exactly
> (or as much as possible) like the type it contains.
>
> Rebinding goes counter to that.
>
Absolutely. And that's why that kind of statement is not in the std 
proposal.

Best

-- 
Fernando Cacciola
SciSoft
http://fcacciola.50webs.com/