Yeah. Take for example the thinking on const generics for user-defined types.
Right now in the Const Generics MVP you can only use integer types. So you can write a generic argument with an u32 N in it, or a char C (a Unicode scalar, so basically a "character" in Unicode) or something like that. There are a bunch of practical uses for this, but obviously there's no reason in principle it must be so limited.
In C++ there's always a temptation to just rip the knob off, sure it might be a terrible idea to make a new type generic over the 32-bit floating point numbers, but that's your problem as the developer right? Just don't do that if you're uncomfortable cleaning up the mess. Rust does not like to provide so many foot guns.
So the last time I looked the proposal was that user-defined types could be eligible for const generic treatment if they derive Eq.
At the first glance that sounds correct, if the type is Eq then it can make sense to be generic over it since apparently we can tell when A = B and thus whether Foo<A> is actually the same as Foo<B> or different.
But then an extra thought brings you up cold. I can claim my type is Eq with one line if it's PartialEq. And I can claim my types are PartialEq just by providing a bogus eq() function that always says false. So isn't this a useless requirement?
And then you study the language more carefully. They're going to require that you get Eq by deriving it. Anybody can implement PartialEq as I described above, but that's not derived. To get a derived PartialEq (and thus Eq) the derive macro has to allow that, and that's only going to work for the kind of composite types a non-crazy person would use for const generics.
Your trivial enumerated type with a list of fifteen types of chocolate bar can easily derive Eq if you want to write const generics so that somebody can make a variable of type AdventCalendar<Chocolate::Mars> in this future Rust version, but my custom type that contains two pointers to C Strings can't successfully derive Eq and so isn't eligible to try to be used for const generics even if it really genuinely implements Eq.
Actually, C++ does limit the non-type template parameters[0] to integral types, enums and function pointers. But some people have found that too restrictive and would like to use other constants as well, like string literals.
Right now in the Const Generics MVP you can only use integer types. So you can write a generic argument with an u32 N in it, or a char C (a Unicode scalar, so basically a "character" in Unicode) or something like that. There are a bunch of practical uses for this, but obviously there's no reason in principle it must be so limited.
In C++ there's always a temptation to just rip the knob off, sure it might be a terrible idea to make a new type generic over the 32-bit floating point numbers, but that's your problem as the developer right? Just don't do that if you're uncomfortable cleaning up the mess. Rust does not like to provide so many foot guns.
So the last time I looked the proposal was that user-defined types could be eligible for const generic treatment if they derive Eq.
At the first glance that sounds correct, if the type is Eq then it can make sense to be generic over it since apparently we can tell when A = B and thus whether Foo<A> is actually the same as Foo<B> or different.
But then an extra thought brings you up cold. I can claim my type is Eq with one line if it's PartialEq. And I can claim my types are PartialEq just by providing a bogus eq() function that always says false. So isn't this a useless requirement?
And then you study the language more carefully. They're going to require that you get Eq by deriving it. Anybody can implement PartialEq as I described above, but that's not derived. To get a derived PartialEq (and thus Eq) the derive macro has to allow that, and that's only going to work for the kind of composite types a non-crazy person would use for const generics.
Your trivial enumerated type with a list of fifteen types of chocolate bar can easily derive Eq if you want to write const generics so that somebody can make a variable of type AdventCalendar<Chocolate::Mars> in this future Rust version, but my custom type that contains two pointers to C Strings can't successfully derive Eq and so isn't eligible to try to be used for const generics even if it really genuinely implements Eq.