12 ms·

C++ has const generics, and they seem to be a lot more powerful, as you can use expressions in template parameters, as long as they can be evaluated at compile

C++ has const generics, and they seem to be a lot more powerful, as you can use expressions in template parameters, as long as they can be evaluated at compile time of course: https://godbolt.org/z/7Tbzhx5Kc https://godbolt.org/z/7Tbzhx5Kc Rust is a very nice language, but I feel they forgot to copy some useful features from other languages.

meithecatte 5y ago
They didn't "forget" to do it, it's just not finished yet.
- cyber_kinetist 5y ago
  The reason: Rust has a different view of how to design type systems compared to C++. They want their type system to be logically more grounded (as the tradition in ML languages like Haskell) rather than the “screw it” template approach. So they’re trying to make const generics logically sound (basically a very limited version of dependent types) and integrate well with the rest of the type system, which is why it’s taking so long.
cyber_kinetist 5y ago
Rust’s generics feels a lot more rigid than C++ templates. In C++ template programming works more like a duck-typed dynamic language (with very esoteric “runtime-like” compile time error messages), while Rust’s type system feels a bit more rigid probably due to its influences from ML-like functional languages. Though there are tradeoffs with each approach: C++ has gained an incredible notoriety for all sorts of wacky template tricks (SFINAE, template metaprogramming, etc…) Thankfully they developed features like constexpr and concepts to remedy some issues with it (the one part of recent committee decisions that I like, though I generally don’t like where the language is going overall)
- zozbot234 5y ago
  Rust uses proc macros for compile-time programming, not generics. These are quite distinct features, with distinct purposes.
- tialaramex 5y ago
  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.
  - gsliepen 5y ago
    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. [0]: https://en.cppreference.com/w/cpp/language/template_parameters#Non-type_template_parameter https://en.cppreference.com/w/cpp/language/template_paramete...
preseinger 5y ago
A language is not just the sum of its features, it's a composite whole. Features interact, and if a language is to be good, those interactions need to be designed rather than incidental. Adding a new feature can very easily deliver net negative value!
mhh__ 5y ago
Try D if you want to see real power in this regard. Want to take a struct value as a template parameter? It just works.

meithecatte 5y ago

They didn't "forget" to do it, it's just not finished yet.

cyber_kinetist 5y ago
The reason: Rust has a different view of how to design type systems compared to C++. They want their type system to be logically more grounded (as the tradition in ML languages like Haskell) rather than the “screw it” template approach. So they’re trying to make const generics logically sound (basically a very limited version of dependent types) and integrate well with the rest of the type system, which is why it’s taking so long.

cyber_kinetist 5y ago

Rust’s generics feels a lot more rigid than C++ templates. In C++ template programming works more like a duck-typed dynamic language (with very esoteric “runtime-like” compile time error messages), while Rust’s type system feels a bit more rigid probably due to its influences from ML-like functional languages. Though there are tradeoffs with each approach: C++ has gained an incredible notoriety for all sorts of wacky template tricks (SFINAE, template metaprogramming, etc…) Thankfully they developed features like constexpr and concepts to remedy some issues with it (the one part of recent committee decisions that I like, though I generally don’t like where the language is going overall)

zozbot234 5y ago
Rust uses proc macros for compile-time programming, not generics. These are quite distinct features, with distinct purposes.
tialaramex 5y ago
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.
- gsliepen 5y ago
  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. [0]: https://en.cppreference.com/w/cpp/language/template_parameters#Non-type_template_parameter https://en.cppreference.com/w/cpp/language/template_paramete...

preseinger 5y ago

A language is not just the sum of its features, it's a composite whole. Features interact, and if a language is to be good, those interactions need to be designed rather than incidental. Adding a new feature can very easily deliver net negative value!

mhh__ 5y ago

Try D if you want to see real power in this regard. Want to take a struct value as a template parameter? It just works.