Disallow the use of `Drop` as a bound

[P1start]

It’s pretty useless to do so, and we might find a use for it post-1.0 for something like &out/&uninit that can’t be dropped.

[sfackler]

Why should Drop be the only trait in existence that can't be used as a bound?

[P1start]

Drop is already a lang item. Calling Drop::drop explicitly is disallowed (for safety reasons), so it’s already special. We might want to change the behaviour of using Drop as a bound in the future, so disallowing it for now would make that a backwards-compatible change. Drop as a bound is basically useless because it doesn’t mean that the type has no destructor, it just means that it doesn’t explicitly implement Drop (e.g., struct Foo(TypeThatImplsDrop); does not impl Drop, but still uses TypeThatImplsDrop’s Drop impl as part of its destructor). Drop is barely a normal trait at all. It has a method, but that method can’t ever be called explicitly. I think that Drop being a trait is merely a convenience that stops us from having to add a special way of adding destructors to things. It certainly should never be used as a bound.

[sfackler]

This should probably live in rust-lang/rfcs, btw.

[P1start]

We don’t have a strict set of rules about when to put issues in the RFCs repo, so I wasn’t sure about where to put this issue. It’s a pretty minor thing, though—no code should be using Drop as a bound today. RFCs issues are (as I understand them) basically placeholders for full RFCs. I think an RFC for something as minor as this might be unnecessary. I’m really not sure, though.

[pythonesque]

I can't think of a reason you'd want it as a bound but I don't see why that means it shouldn't be legal. I can't think of a reason you'd use StrPrelude as a bound either, but it's still not disallowed. It would be better to go in the other direction and make drop take self instead of &mut self so it could be called as a normal function (IIRC that's the only reason it can't be called? Obviously the code generation would still be different).

[P1start]

But we might want to allow Drop as a bound in the future with some other meaning. Disallowing it as a bound now will give us the flexibility to add a better meaning backwards-compatibly later.

[pythonesque]

There's nothing stopping people from writing a new trait called Drop, though. We have multiple Slices even though one of them is in the prelude.

[steveklabnik]

These days, a change like this would require an RFC. @P1start if you still feel strongly about this, please file one!