I am not I'm on the compiler team. I am part of the const eval working group though, which reports directly to the lang team, so I guess that's splitting hairs on my end.
I am not trying to shoot down the discussion or force my opinion to be accepted by everyone. I am indeed unhappy that there is such a strong push for duck typing style const generics, but that's beside the point, as that is just my personal feelings about it. With associated types these have not been so much of a problem yet, because people mostly use them to convey values, not computations. With const generics, as the discussion shows, people want to use them for computations.
I want us to find a good solution that satisfies everyone, but I am very conservative here (lol), because of the already mentioned problems we've had with post monomorphization errors happening unexpectedly in the past. I really do want to be able to build convenient and non-spammy APIs. I have suffered from overly verbose typenum declarations myself.
What we can do in a future edition is to default
const fns to
nopanic and require
panic annotations to swap the rules here, but beyond that I don't think we can do a change like you are suggesting. We have the same problem with adding a new
? bound, someone's ral code out there will break.
What I would like is that we implement all the experimental nightly things with const-evaluatable-unchecked (as you can implement everything with that), and then figure out what recurring things are problematic and start collecting the various cases.
If it is just the fact that the array hack is annoying and you understandably don't want to recreate a
struct Foo<const X: usize>; to use in bounds, we can start bikeshedding a syntax for such bounds sooner rather than later.