Consider renaming Drop::finalize to Drop::drop

[erickt]

This is to address a XXX in src/libcore/ops.rs. I'll convert it into a proper fixme.

[catamorphism]

Seems like more of an RFC?

[pcwalton]

+1. It's just a keyword issue. (Although we might want to keep the drop keyword around to indicate where the flag is)

[brson]

I-nominated (backwards compatible)

[graydon]

Accepted for backward compat

[erickt]

Now that I've removed the old drop support, there should not be anything else holding up this change.

[bstrie]

I tried to do this today, but the compiler is still complaining about finding drop in ident position. I'm guessing this means that we need to wait for another snapshot.

[glaebhoerl]

With deepest apologies for bikeshedding: how come not Destruct and destruct()? It's usually referred to as a destructor, even by the Rustic. Why call it anything different?

[bblum]

+1 for drop

[luqmana]

So will drop be kept as a keyword but allowed in the ident position or will it just be removed altogether as a keyword?

[bstrie]

@luqmana I can't think of any reason not to remove it as a keyword altogether. I suppose someone might write a trait with a .drop method and then later get flustered if they try to add a destructor to it, but we have no precedence for reserving the method names of other magical opt-in traits, such as .add.

[graydon]

Non keyword, use "drop". Destruct sounds awkward and will make everyone ask why it's not called destroy.