One thing I feel this thread is lacking is a good/great reason for adding this new syntax to support this feature. The feature itself sounds great, but what benefit does the additional syntax provide? i.e.
impl<T; const N: usize> vs
impl<T, N: usize>
It seems like this additional syntax
const is just unneeded baggage surrounding this feature. If the generic param is a "sized type", then it is very intuitive to know we need to supply a const value of that type. Additionally, if it is not as intuitive as I think, it seems a case where we can have really good error messages and in general docs.
Tying my argument to the ergonomics inititive:
Applicability. Where are you allowed to elide implied information? Is there any heads-up that this might be happening?
While not the most frequently used feature, it will still be used often enough to add unneeded friction while learning but especially as an experienced developer.
Power. What influence does the elided information have? Can it radically change program behavior or its types?
The proposed syntax has zero influence on program behavior. Regardless of the additional syntax, if the user of this particular generic puts in the wrong value, there would be a compile time error with hopefully good error messages.
Context-dependence. How much of do you have to know about the rest of the code to know what is being implied, i.e. how elided details will be filled in? Is there always a clear place to look?
Regardless of the additional syntax, the user needs to know the signature of the generic they are trying to use, and likely already has its rustdoc open. The only additional context is that when a "sized type" is a generic parameter it requires a const value during use. While arguably intuitive, this is a very simple rule which only needs to be learned once.
Finally, if a developer has a personal preference to have this distinction in their code: They are not restricted from using comments to add this distinction to their source files. eg.
impl<T, /* const */ N: usize>