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

From: David Abrahams (dave_at_[hidden])
Date: 2005-10-15 13:21:35

Joel de Guzman <joel_at_[hidden]> writes:

> David Abrahams wrote:
>> Joel de Guzman <joel_at_[hidden]> writes:
>> 
>> 
>>>>Rebinding semantics are there _precisely_ and _only_ to solve a problem 
>>>>posed by nullability.
>>>
>>>Sorry, I don't buy that.
>> 
>> Why not?
>
> I think this is again an artifact of the confusion between the
> dual interfaces that optional provides. optional has an identity
> crisis of being a pointer (as the author's original model) and
> a variant<T, nil> (which I suggested later on). The rebinding
> behavior that Fernando rationalized was long and winding and
> confusing. I don't recall anymore his exact rationale. All I
> know is that when you have to explain your design using so much
> wordings, then something is wrong, and I don't buy the gobbledegook.

I *really* don't have an opinion about what the right choice should
be.  That said, terms like gobbledegook seem needlessly judgemental,
and as such I think they only cloud the issues.

> There *is* an alternative design which is a lot simpler and I've
> been saying that again and again: do as the structs do. 

I guess you're assuming optional<T&> maps onto a struct with a T&
member?  That model is not 100% obvious to me.  The only way to
initialize a plain struct with a reference member is using an
initializer list, and the assignment operator for such a struct can't
be used.

  struct X { int& y; };
  int z = 3;
  X x = { z };
  X y( x = x );

--
  "ComeauTest.c", line 1: error: implicitly generated assignment operator cannot copy:
              reference member "X::y"
    struct X { int& y; };
           ^
            detected during implicit generation of "X &X::operator=(const X &)"
                      at line 5
So "the structs" in this case are never that simple, and they don't
provide a guide for what to do with optional<T&>, since the assigment
behavior for reference members is always explicitly decided by some
class designer.
> It is easier to visualize and understand and ultimately to explain.
> A more complex design and behavior will surely lead to more gotchas.
Seems to me there's plenty of room for confusion in the behavior you
want.
  optional<X&> o;
  X x;
  o = x;           // Reference bound; no copy ctor called.
  o = x;           // X's copy ctor called
> Keep it as simple as possible. variant<T&, nil> does
> the right thing. I don't understand why optional can't. 
Surely it _can_ do the same thing as variant<T&, nil>.  It's just not
as obvious to everyone that it's the "one true behavior" for
optional<T&>.  It's not like we're discussing the choice between Emacs
and every other editor on the planet ;-)
> Perhaps it's because of the dual pointer interface. But, like Mat
> Marcus, I also don't buy the pointer model: "Pointers can be null or
> dereference-able, Optionals can be null or dereferenceable,
> therefore Optionals are models of Pointers". 
I don't know if anyone actually made that argument or not, but
optionals don't have to be models of Pointers in order to justify the
operator*, operator->, and operator safe_bool.  The Pointer and
Optional concepts could be refinements of some concept that includes
nullability and dereferenceability.
I'd really like to see a careful and non-judgemental comparison of the
two possible design choices, describing the advantages and
disadvantages of each one.  Until we see something like that, I doubt
we will be able to come to a useful consensus.
-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com