Adding a `Drop` impl to a type is a breaking change

[oli-obk]

uncommenting the drop impl in the following program causes it to not compile

struct Foo;

/*
impl Drop for Foo {
    fn drop(&mut self) { }
}
*/

const fn new(_: Foo) { }

if the definition of Foo were in another crate, adding that Drop impl would break compilation of the crate with the const fn.

cc @Centril

I don't think adding a drop impl was a breaking change before const fn. But maybe I just can't come up with an example.

[Centril]

Not exactly sure what is wanted from the lang team here; the description here is accurate.

But maybe I just can't come up with an example.

//#[derive(Copy, Clone)]
struct Alpha;

struct Beta;

struct Foo(pub Alpha, pub Beta);

//impl Drop for Foo { fn drop(&mut self) {} }

fn new(x: Foo) {
    let _a = x.0;
}

This needs at least one public field which isn't Copy.

[petrochenkov]

let _a = x.0;

This case is fixable (there was an RFC allowing this in 2017-2018, but I can't find it), but things are currently moving in the opposite direction with that RFC being closed and rust-lang/rfcs#2514 + #56440 being accepted.

[oli-obk]

Not exactly sure what is wanted from the lang team here

Well, this is a regression in the language, so I assumed the lang team would be the relevant team to figure this out.

Since there is an example that shows that adding Drop impls to types is a breaking change even ignoring const fn, there's nothing to act on here I think.