> And before that, in the pre-alpha days of Rust, arrays were defined with a variadic macro. The /* something */ above was a [T, ..$N], where T is the type, and ..$N defines a range (I believe -- old Rust is weird) up to the number of specified elements.
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.
From the naive lens of someone writing C++, this all looks... extremely elementary. The first half of the blog post touts monomorphization, which (to my otherwise uneducated eyes) is nothing other than what template instantiation does in C++, no? And the second half is dedicated to the technicalities of why it's hard to make the compiler support the equivalent of the following C++ signature:
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?
I appreciate the attention to the social and organizational aspect of implementation here. Every piece of software has a somewhat nonlinear curve in the difficulty of adding new features as the codebase gets more complex, but it's especially bad in compilers. Adding something as complex and all-pervasive as dependent types - and this is dependent types, just in a Rusty costume! - is, clearly, on another level. I'm very excited for a more capable incarnation of this feature, but I'm not holding my breath for its stabilization.
Is monomorphization truly 0-cost? I thought it's basically a different flavor of optimizing inliner (somewhat more under user control) which has a similar tradeoff curve between whether it's better to stamp out a monomorphized version of a function or if it's better to operate on more opaque type signatures.
Major pet peeve...
> 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.
Similar to constant generics, any idea what `~const` means ?
I can see some references in the source code, https://doc.rust-lang.org/src/core/result.rs.html#2057
> And of course, this leads to any further optimizations the compiler may decide to do, re: inlining.
Ah, so just like languages with 'runtime' generics like c# and java!
Great article! I would just like to add to the point about C# generics.
> "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...