|
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