Repository navigation
Stabilization error E0658 is trivially bypassed #90912
Description
trait IsMagic {}
const fn foo<T>() where T: IsMagic {} // Does not compile
const fn bar<T>() where (T,): IsMagic {} // Compileserror[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.
Reacted by Jake Goulding, oli, zohnannor, Diana and Martin Habovštiak
Activity
[-]Stabilization error E0659 is trivially bypassed[/-][+]Stabilization error E0658 is trivially bypassed[/+]RalfJung commentedon Nov 15, 2021
Cc @rust-lang/wg-const-eval more holes in our guard against trait bounds...
fee1-dead commentedon Nov 15, 2021
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 designconst_trait_impl, and we should just use something like~const.oli-obk commentedon Dec 24, 2021
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 commentedon Dec 24, 2021
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 commentedon Dec 24, 2021
Yea, the terminology is weird. How about "removing an unnecessary and circumventable feature gate", wordy but doesn't suggest we get const trait bounds
Rollup merge of rust-lang#93827 - eholk:stabilize-const_fn-features, …
jplatte commentedon Mar 22, 2022
#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
?constinstead of~constafterall... #93706 (comment)