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