> "generics in Rust are zero-cost abstractions. rustc performs a process called monomorphization, where generic items (methods, structs, etc.) are "flattened" at compile time into only the types that are used. (Compare this to a language like C#, where generics are evaluated at runtime.)"
I believe that generics are evaluated at runtime in C# due to just-in-time compilation. C#'s implementation of generics (which they call reification) is more similar to Rust's monomorphization than, say Go and Java's lookup table type erasure approach.
More information about this can be found here: https://stackoverflow.com/questions/31876372/what-is-reifica...
btw. it's not called "runtime evaluation" and more or less a kind of runtime substitution. (because nothing gets evaluated it gets substituted)
and btw. c++ allows references types to have specializations, this is not possible in c#
template<int N>
std::array<int, N+1> foo();
Am I missing something that makes Rust generics way more complicated than C++ templates? Or is retrofitting them into Rust really such a hellish adventure?
The main difference is that the C++ code will check everything at instantiation time, and C++ templates can lead to nasty error messages because it's hard to assign _blame_ to either the caller or the callee.
As an example, consider the following code:
template<int N>
std::array<int, N> foo() {
std::array<int, (N / 2) * 2> out;
return out;
}
Rust takes the approach of requiring that you specify constraints on generic parameters up front. It then checks whether the function's body will compile _for all_ possible generic parameters, given the constraints. This is much easier to use from a usability perspective, since you know whether to blame the caller or the callee, and it explicitly enumerates the requirements that you need to meet (i.e. the constraints on the generic parameter) in order to get your code to compile. This is why C++ lets you do many more crazy things with templates than Rust currently allows you to with generics (and why is moving more slowly to add things to its type system).
C++'s alternative approach gives up usability for extra flexibility. Neither approach is "right." They're just different trade-offs.
(As an aside, it turns out that the Rust type system was Turing complete even before const generics were added.)
Provides you with an example to play with, as described this is broken for foo<5> but works fine with say, foo<6>
I can see some references in the source code, https://doc.rust-lang.org/src/core/result.rs.html#2057
const functions are really 'maybe const' functions since they can be called with runtime arguments or compile time arguments.
If you want your const function to depend on some trait, for it to even be possible at compile time, those traits would need to be possible to use at compile time too.
But the same idea holds as arguments, we might just want to use it at runtime too, in which case it needs to be a 'maybe const' bound for the const function to be flexible enough for us.
This is just a misunderstanding. The `..$N` was just the array length syntax. Now the syntax is `[T; N]` with no change in meaning - there was no variadic magic.
> Let's look at a brief example to get familiar with syntax:
Followed by no explanation, nor is there a target audience laid out in the article.
Now I'm left simply thinking it's a terrible article because it's starts with a poor explanation targeted at anyone.
If it started with "if you're familiar with C++/go/c#/whatever then this syntax should appear familiar", then I would have quietly closed the article. Unfortunately my impression of the article is poor, and continues to be poor of the rust community because of constantly putting out content with this style of hand wavy introduction that makes outsiders feel more alienated.
At least haskellers (of which I am not one) manage to be aware of this trope in their own community.
Ah, so just like languages with 'runtime' generics like c# and java!