impl<const N: usize> Copy for Foo<N> where Assert::<{N < 128}>: IsTrue {}
The Assert::<{N < 128}>: IsTrue {} part does not look so nice, we can see that it is a non-obvious encoding of the idea of compile-time conditions. It’s good that it is expressible, but the fact that it is a non-obvious encoding has many costs (discoverability, teachability, the quality of error messages when using the idiom, etc.) that would go away with proper language support for compile-time conditionals, or could be better avoided by using language machinery to facilitate library-side encodings (macros as a start but more generally “active libraries”: having the choice of error messages be partly decided on the user side, etc.).
The Haskell community is excellent at pushing the boundaries of what can be expressed in the language through various encodings (typically various encodings of type-level records using type-classes to describe ORM schemas, effects, capabilities, etc.). But the usability of the final result can be disappointing.
Does this mean type-checking in rust is about to become turing complete?
It already was, but there’s a stack limit
Practically, procedural macros are in every way worse for compilers.
After a year-and-a-half hiatus from Rust, I’m looking forward to releasing a Rust data structure library that uses const generics in its API!
Very exciting, may I ask what the library is?
A zero-copy dynamic array.
Nit-pick:
If I’m not mistaken, that’s still 5 days away.
Yeah, something’s wrong with my Hugo setup…
No no, Rust is just that fast.
The
Assert::<{N < 128}>: IsTrue {}part does not look so nice, we can see that it is a non-obvious encoding of the idea of compile-time conditions. It’s good that it is expressible, but the fact that it is a non-obvious encoding has many costs (discoverability, teachability, the quality of error messages when using the idiom, etc.) that would go away with proper language support for compile-time conditionals, or could be better avoided by using language machinery to facilitate library-side encodings (macros as a start but more generally “active libraries”: having the choice of error messages be partly decided on the user side, etc.).The Haskell community is excellent at pushing the boundaries of what can be expressed in the language through various encodings (typically various encodings of type-level records using type-classes to describe ORM schemas, effects, capabilities, etc.). But the usability of the final result can be disappointing.