{I tried to post this with Outlook Express but after waiting about a day I
don't see it posted and I never recieved any moderation message.. so I guess
there something wrong with OE}

Hi People,

I'm the author of the std::optional<> proposal (n1878)
I couldn't go to the meetings personally but Thomas Witt was kind enough to
champion it for me there.
Thank you Thomas!

There were two major concerns I'd like to address here (in two separate post
to keep them focused)

[I'll paste here fragments of the conversation on the boost lists were the
discussion started]

value access interface
======================

Matt Marcus raised the concern that the use of these operators in the
interface strongly suggested to many people (and not just juniors) that
optional<> had shallow semantics. (when it doesn't).
He reported that he faced confused users himnself.

> Pointers can be null or dereference-able,
> Optionals can be null or dereferenceable,
> therefor Optionals are models of Pointers".

No, they are both different models of the smae concept.

> At best, this would argue that Optional and Pointer
> have one dimension of commonality, i.e.
> perhaps they would both model a more primitive
> concept (Nullable?).

Precisely... both optional<T> and pointers are models of a common concept.
In Boost that is called OptionalPointee
(http://www.boost.org/libs/utility/OptionalPointee.html)
I left the OptionalPointee concept (which now I kind of like calling it
Nullable)
outside the proposal to avoid complicating it.
It seems that I better include it in the update.

> But there is also a dimension of variability,
> in particular, Optionals have deep-copy semantics,
> while pointer-like syntax suggests shallow copy semantics
> to many users

That "pointer-like syntax suggests shallow copy semantics to many users"
is an unfortunate fact, but fact nevertheless.
OTOH, serious programmers should RTFM, or at the very least, care to know
the semantics of what they are going to use from a source better that what
the interface suggests.

I agree that at some extent the interface might suggest the wrong thing, yet
OTOH and at the same time, I claim that it suggest just the right thing:
that the value being accesed might be absent.

But its not just what the interface suggests:

That both optional<> and pointers/iterators are models of the same concept
(call it OptionalPointee or Nullable) is important because one can make use
of that. But then, that they share the interface that corresponds to such a
common concept is fundamental because it allows generic code to use the
concept.
I think it would be a mistake if optional<> were not modeled after
OptionalPointee just becasue many users relate dereferenciability with
aliasing. I rather stress out the difference and try to help authors and
instrustors to teach it for good.
Something similar happened with iterators, most people related access with
traversing, as if they were actually related. Of course the former iterators
categories helped with this view; but now we're past that thanks to the new
iterators proposal from Dave Abrahams.

I think the "problem" here is not optional<>'s proposed access interface but
the common misconception that dereferenciablity and aliasing go hand in
hand. That's plain wrong and optional<> can be thought of a step toward
removing that misconception.

Dave Abrahams asked in the boost list:

> I'm just wondering, for those listening, whether the
> deep-copying smart pointers often used for the pimpl idiom
> raise the same concerns

Do they?

Best regards

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


---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]