clear() and UFCS

Jonathan M Davis jmdavisProg at gmx.com
Sat May 26 10:44:06 PDT 2012


On Saturday, May 26, 2012 14:00:15 Jacob Carlborg wrote:
> On 2012-05-26 03:38, Jonathan M Davis wrote:
> > clear and delete are very different things. It was definitely decided that
> > we'd be better off without delete. It's going for good. Renaming clear to
> > something that doesn't conflict so easily with more benign functions is
> > completely different from bringing back delete. Bringing back delete
> > isn't even on the table at this point.
> > 
> > - Jonathan M Davis
> 
> Why can't "delete" do what "clear" does. Backwards compatibility?

I would think that that would be a bad idea, because it wouldn't be doing what 
delete does in C++ at all and would be really confusing to a lot of people. It 
would probably work without them realizing what was going on (since it's 
stupid to do anything with a deleted object other than assign it a new value, 
which would work with clear), but it would end up with very different behavior 
memory-wise, causing unexpected behavior.

Another problem is that we're trying to discourage using stuff like clear 
unless you actually need to and know what you're doing, whereas delete is used 
all the time in C++, because it doesn't _have_ a GC built in. So, having clear 
as a language construct rather than a function is arguably a bad idea, because 
it elevates it to something more normal. If it's delete, a lot of people will 
just use it without learning what's really going on, whereas they'll have to 
actually learn about clear to use it.

Also, it  would have a negative effect on ported code to change clear to 
delete. If delete is illegal, then the compiler will catch it when you forget 
to remove it from ported code, whereas if it just does what clear does, you 
could end up with deletes left in when you didn't intend to, but now they have 
different semantics.

- Jonathan M Davis


More information about the Digitalmars-d mailing list