As far as I understand, the primary issue blocking specialization is lifetimes. They cannot affect the runtime behaviour of the program, so we cannot rely on the exact inferred lifetimes for trait resolution. Thus specialization on lifetimes is hard to impossible to implement soundly, and everything which can lead to lifetime specialization is also blocked. For example, we cannot specialize on types in general, because those types can have lifetimes, leading to lifetime specialization.
However, I don't see how specializing on the values of const generic parameters could lead to lifetime specialization, in the current implementation. Currently it's impossible to provide arbitrary types to const generic parameters, only
char and integers can be used. As far as I can tell, this makes it impossible to cause lifetime specialization using const specialization: the types are specific, and while the expressions for constants could, in principle, contain lifetime-generic types, the values of the constants cannot depend on it (because it's impossible to define different values of a constant for different instantiations of lifetime parameters).
This is a significantly restricted subset of
min_specialization. I couldn't find any somewhat-recent status for
min_specialization, but I heard that it also had some soundness issues.
The motivation for
const_specialization is making array types more useful. Currently many core traits (
Serialize/Deserialize) in the stdlib and libraries are not implemented for arrays. The reason, I believe, is because those traits were already unconditionally implemented for
[T; 0] for any
T, but for
[T; N] would require extra trait bounds on
T. This means that the array impls cannot be added backwards-compatibly without some form of specialization. This is a source of frustration for use cases where fixed-sized arrays are common, like various kinds of low-level binary protocols. The proposal is to make that specific use possible.
The primary objection to this feature that I can see is that it is unclear whether it will fit as-is in the future final design of specialization, whether it would require some syntactic or semantic changes, or even whether full specialization will ever be possible. In my eyes the motivation for const specialization is strong enough to warrant it even if the larger design requires a different approach. Also, so far I haven't seen any radically different specialization designs, so it feels like the discussion is over the soundness and implementation of the feature rather than its basic syntax and capabilities.
Some future additions to const generics would also be at odds with this minimal
const_specialization. For example, there would likely be conflicts if the type of constants could be arbitrary (or even just
&str for any lifetimes). Since constants are always
'static, this doesn't immediately look like a blocking conflict, but perhaps some more complex group of generic types and traits could still cause the issue. Overall, it would mean that only one of those features could be stabilized without solving full specialization. Imho since zero-sized arrays is such a common and basic issue, it should take priority over complex const expressions, but I can see the converse arguments.