Boost logo

Boost :

From: Mat Marcus (mat-lists_at_[hidden])
Date: 2005-10-12 09:42:22


On 10/11/05, David Abrahams <dave_at_[hidden]> wrote:

Aleksey Gurtovoy <agurtovoy_at_[hidden]> writes:

>> You might explore a interface here on boost which did not have the
>> pointer interface,
>
> Over my dead body ;). That's the interface we use here at Meta, and to
> say that our 'boost::optional' usage is extensive would be an
> understatement. We don't care for 'get', though.

Having not used optional extensively, I don't have a strong opinion on
which interface might be better, but it's been my experience that
objections to the pointer interface seem to be moral positions not
backed up by any sound technical argumentation. That said, moral
positions count when they are connected to votes in the committee, so
if there's a general consensus against the pointer interface there,
the onus is on those in favor of it to produce sound argumentation in
favor.

--
Dave Abrahams
Dave's "experience" of the objections to the pointer-like syntax as
being "moral positions not backed up by any sound technical
argumentation" would have been different had he actually been present
at the discussion.
Here are a few of the objections to the pointer interface that were
raised in the discussion:
1) At a large company, I promoted and supported the use of
optional. It was my experience that the pointer-like syntax
confused a number of programmers. They were not "junior"
programmers. The confusion centered around whether optional<Foo>
had value semantics or pointer semantics, especially under copying.
(Ironically, when the straw vote was taken as to whether to
continue pursuing optional for the standard, I voted a "strong
yes", while another committee member indicated that he was
presently leaning towards a no vote since "we have enough
shared_ptr-like components in the library already". Of course, as
the proposal advances further, I expect him to study it more
carefully.)
2) Regarding the Concept behind the pointer-like interface--an
argument like the following argument would not work for me:
"Pointers can be null or dereference-able, Optionals can be null or
dereferenceable, therefor Optionals are models of Pointers". 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?). 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.
I did not claim that there were no arguments that the pointer-like
interface was technically sound. Rather I suggested that we ask the
author to consider the objections and if he was still convinced of
the correctness of the interface, to provide us with rationale
beyond that found in N1878. N1878's argument that "from syntax
alone, [the pointer-like syntax makes it] loudly clear that the
value being accessed might be absent" is offset in my mind by the
fact that I have seen the syntax incorrectly suggest pointer-like
copy semantics to users. My field experience supporting optional
contradicts N1878's claim "the confusion is harmless".
3) Other committee members didn't want to see both a "get" and a
pointer-like interface.
To be fair to Dave, perhaps his impression came from a later
discussion that we had in the lobby. In that discussion, after a
while, we moved from the objections to optional's pointer-like
interface to a discussion, "by analogy", of whether it was reasonable
for string concatenation to be spelled "+". I argued that it was an
embarrassment, since in mathematics "+" suggests that a+b == b+a, and
I said that if we had to have an operator syntax for concatenation I
might prefer "*". Dave argued that most programmers don't recall the
meaning of the word Abelian, and that "*" would make for many unhappy
programmers. From there we started talking about other languages. Of
the lobby discussion, it could be said that there was "moralizing" in
the air. (Please, let's not get into a discussion of std::string
here).
- Mat

Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk