From: Michael Fawcett (michael.fawcett_at_[hidden])
Date: 2007-10-11 16:22:03
On 10/11/07, Marco <mrcekets_at_[hidden]> wrote:
> I understand your analogy but anyway if we agree that in your example
> sets/includes "bar" discards "foo" automatically there is no ambiguity
> that we have to check.
Discarding "foo" *IS* resolving the ambiguity. Discarding is the
method overloads implemented to resolve ambiguity, but it doesn't mean
that the user wasn't introducing any.
> Then if you want only to state that this behaviour could be not obvious
> for the user, I can only say that, IMO, this is more a documentation
> than an implementation problem.
Yes, it's a documentation issue.
I think you get my analogy. Calling include/set has the potential to
overwrite something, just like insert on a std::set has the potential
to fail if a duplicate already exists (for that reason alone I would
argue against "insert" since it has exactly opposite behavior w.r.t.
If the user chooses to ignore that return value std::pair<bool,
iterator> and is surprised by the result, it's his own fault for not
reading the documentation and his own fault for not catching the
We are arguing trivial things. 'include', to me, has the most
relevant connotations and precedents, and I'll leave it at that.
Wonderful work to all the authors, regardless of what name you choose!
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk