Meaning of .clear() for containers

[Jonathan M Davis]

On Thursday, January 06, 2011 10:47:11 Jérôme M. Berger wrote:
> Steven Schveighoffer wrote:
> > I don't expect this to be a huge problem.  Will people who more likely
> > destroy an object with:
> > 
> > clear(obj);
> > 
> > or
> > 
> > obj.clear();
> > 
> > ?  To me, the first looks like you are doing an operation to the object,
> > where the second looks like you are having the object do an operation.
> > 
> > UFC is going to cause lots of these little corner cases.  Another I can
> > think of is global properties.  with @property foo(int x), do you call
> > this as foo = 1; or 1.foo?
> 
> 	I believe this becomes a problem when you have *both* a free
> standing function (to destroy the container) and a method (to empty
> it). And yes, this will crop up a lot with UFC.

Yes. It would almost certainly have to make it so that the compiler used a 
member function when there was a choice between a member function and a free-
standing function and overloading does not make it clear which to use. 
Unfortunately, that would mean that which function would be called could change 
when a member function was added or removed, but I don't see any way around 
that. Still, much as clear is a good name for both the free-standing function 
and the member function. Perhaps one of them should be changed, regardless of 
the state of UFC.

In theory, we're going to get UFC at some point, but this sort of issue may make 
it unreasonable to implement. We'll just have to wait and see until it's 
actually implemented, I suppose.

- Jonathan M Davis