Stabilization error E0658 is trivially bypassed

[Diggsey]

trait IsMagic {}

const fn foo<T>() where T: IsMagic {} // Does not compile
const fn bar<T>() where (T,): IsMagic {} // Compiles

error[E0658]: trait bounds other than `Sized` on const fn parameters are unstable

I already have code unintentionally relying on this, so please don't break it 😅

The first case should probably just be stabilized, since you can already rely on it.

Also, the stabilization issue the error message references doesn't actually mention this error, so it's not clear what work is left to do on it.

[RalfJung]

Cc @rust-lang/wg-const-eval more holes in our guard against trait bounds...

[fee1-dead]

I'm inclined to just remove the const_fn_trait_bound feature altogether. It doesn't error for Newtype<T> and not even (T,). IMO it doesn't have anything meaningful use for how we should design const_trait_impl, and we should just use something like ~const.

[oli-obk]

We got "preliminary lang team approval" to just allow trait bounds, trait objects and fn ptrs in const fn, but not allow using them in any const way beyond accessing associated consts. So no method calls or anything. I think the right way forward would be to split the feature gates, but tbh, I think it would be totally fine to just open a PR that stabilizes trait bounds, trait objects and fn ptrs and then FCP that PR

[fee1-dead]

I would rather use the term "remove" than to "stabilize" here, but could it be confusing to users on whether the restriction was lifted or remained an error just like without the feature gate enabled?

[oli-obk]

Yea, the terminology is weird. How about "removing an unnecessary and circumventable feature gate", wordy but doesn't suggest we get const trait bounds

[jplatte]

#93827 removed this stabilization error, so maybe this could be closed? However, I'd really prefer if we could take a step back, revert that stabilization and consider an edition-based flow for getting ?const instead of ~const afterall... #93706 (comment)