`~const Drop` bounds are broken / wrong / unsound

[steffahn]

#![feature(const_trait_impl)]

fn extend_lifetime(x: &str) -> &'static str {
    f::<S>(x)
}

const fn f<'a, T: Tr<'a> + ~const Drop>(x: &'a str) -> T::Ty {
    // can call g with T: Drop bound, even though
    // T: ~const Drop works for non-Drop-implementing types
    g::<T>(x)
}

#[allow(drop_bounds)]
const fn g<T: Drop>(x: &str) -> <T as Tr<'_>>::Ty {
    x
}

struct S;
trait Tr<'a> {
    type Ty;
}

#[allow(drop_bounds)]
impl<'a, T: Drop> Tr<'a> for T {
    type Ty = &'a str;
}

impl<'a> Tr<'a> for S {
    type Ty = &'static str;
}

fn main() {
    let x = "Hello World".to_owned();
    let s = extend_lifetime(&x);
    drop(x);
    println!("{s}");
}

��)

(playground)

@rustbot label requires-nightly, I-unsound, T-compiler, F-const_trait_impl, A-const-fn

By the way, even if this worked “correctly” (i.e. soundly) I really hate the fact that this feature is using a sort of T: Drop bound; the drop_bounds warning exists for a reason, using the Drop trait in bounds is discouraged for a reason, abusing it as in the feature that allows “T: ~const Drop” makes everything just sooo much more confusing and inconsistent.

[compiler-errors]

cc @fee1-dead @oli-obk

[oli-obk]

I really hate the fact that this feature is using a sort of T: Drop bound; the drop_bounds warning exists for a reason, using the Drop trait in bounds is discouraged for a reason, abusing it as in the feature that allows “T: ~const Drop” makes everything just sooo much more confusing and inconsistent.

FWIW I agree. I brought some of this up in https://rust-lang.zulipchat.com/#narrow/stream/146212-t-compiler.2Fconst-eval/topic/.22implicit.22.20const-if-const.20Drop

We can't automatically require all generic params to be const droppable, as that would make const fn foo<T>(T: T) -> T {t} stop being callable in const contexts with types that implement Drop, which works right now on stable.

[steffahn]

@oli-obk Looking at the linked discussion I don’t see where this brings up the same point. Maybe I’m missing something.

In my mind, there should be a trait CanBeDropped¹ (that can’t be implemented manually) that is always (non-const-)implemented by all types T: ?Sized², but then a type also implements T: const CanBeDropped whenever all Drop implementations called in the destructor of T are const Drop implementations.

I.e. for a type with no drop glue at all, the destructor invokes no Drop implementations at all, so all of them are const Drop implementations. For a struct S with field types Foo and Bar, we get S: const CanBeDropped if and only if both:

• S implements const Drop, or doesn’t implement Drop at all
• Foo: const CanBeDropped and Bar: const CanBeDropped (checked recursively)

The necessary bound for dropping some type T in a const fn then would be T: ~const CanBeDropped. As mentioned, the bound T: CanBeDropped is fulfilled automatically by all types, so the bound doesn't hurt non-const function calls.

Obviously, this approach would also get rid of the limitation under the current rules that impl const Drop for ... requires all fields to be const Drop.

Footnotes

1. actual name TBD ↩

2. types that don't implement it might exist if we get linear types; so it might be possible to use the same “CanBeDropped” trait for const destructors as well as linear types, but I haven't thought this through whether or not there might be any significant differences/incompatibilities ↩

[fee1-dead]

Issue seems to be resolved after #94901.