On 10/11/07, Marco <mrcekets@gmail.com> 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. set/map). 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 return. 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! :) --Michael Fawcett