const BMCR_SPEED100 := uapi::BMCR_SPEED100;

Posted Jul 1, 2025 2:34 UTC (Tue) by neilbrown (subscriber, #359)
In reply to: const BMCR_SPEED100 := uapi::BMCR_SPEED100; by adobriyan
Parent article: How to write Rust in the kernel: part 2

> I, for one, think that compile time constants should be in ℤ for as long as possible

Or ℚ. go-lang claims to keep full precision for constants. I think it does for integers, but rationals become floats too soon I think (last I checked).

to post comments

const BMCR_SPEED100 := uapi::BMCR_SPEED100;

Posted Jul 4, 2025 11:30 UTC (Fri) by massimiliano (subscriber, #3048) [Link]

What go-lang does is nice in theory, but it has the side effect of having a sort of "language inside the language" for const values, which has the same syntax as the more general go-lang but different semantics. That "language" is used to compute const-expression values and nothing else.

What I do not like about the go-lang approach is that this "const-expression language" is very specific and cannot apply to user-defined types with const values. It is OK for go-lang because of its poor type system, but IMHO it would make no sense in Rust.

In Rust there's this concept of "const context", where one can use a subset of the regular Rust language and know that it will be evaluated at compile time, but (crucially) this works for any type, not just primitive ones.

Over time, the subset of Rust usable in const context gets larger. Still, the language itself (and its semantics) remains the same, and I deeply appreciate the cleanliness of this approach and the fact that I can write entire functions that work on my own types and have them evaluated at compile time.

Now, this is not Zig's "comptime"... for that, there are macros, but this would open a different can of worms!