4 ms·

To be honest `comptime` seems excessive. Like, if something can be calculated at compile time, it should be. Why the extra keywords for that? Rust is mostly doi

by Svoka 2y ago

To be honest `comptime` seems excessive. Like, if something can be calculated at compile time, it should be. Why the extra keywords for that? Rust is mostly doing it already.

staunton 2y ago
> if something can be calculated at compile time, it should be Often you don't actually want some things done at compile time although they could be done. It can lead to, e.g., excessive executable sizes, excessive compile times. If you've ever considered using `-ftemplate-depth` in C++, you've probably encountered such a case. Maybe it sounds like I'm splitting hairs and you would say "of course in such crazy cases it's not true", but if you look at C++ projects and what can be done at compile time with modern C++, you would find it's not rare at all.
- tomjakubowski 2y ago
  Yes. My attitude earlier in my life as a programmer was that moving as much as possible to "compile time" was a universal good. The truth is of course, like everything, there are trade offs. I once worked on an Elixir application whose configuration was accessed almost exclusively at compile time. This was done with the well-intended notion that saving runtime cycles was a good thing. It meant that changing any config (e.g.: "name of s3 bucket") meant recompiling the entire application. It also meant we had to wait for a full application rebuild in CI to deploy fixes for simple configuration errors. Not so super.
trealira 2y ago
One reason you might want an explicit keyword is so that it fails to compile if it can't be calculated at compile time, which is what was intended, rather than fall back to calculating it at runtime. It also seems useful as an ad-hoc method of annotating pure functions; those functions are guaranteed not to modify global variables at runtime or do I/O.
- Svoka 2y ago
  I guess so... This is reason for `consteval` and such.
samatman 2y ago
The comptime keyword is only needed in Zig if the code could execute at runtime. It forces compile-time evaluation, but it isn't the only way for it to happen. So Zig actually does what you seem to think it should do (and I agree! it's great!): if something can be calculated at compile time, it is. Only when the compiler can't statically deduce a compile-time construct is it necessary to use the `comptime` keyword: in fact, it's an error to use the keyword when the context is already comptime.

by Svoka 2y ago

To be honest `comptime` seems excessive. Like, if something can be calculated at compile time, it should be. Why the extra keywords for that? Rust is mostly doing it already.

staunton 2y ago

> if something can be calculated at compile time, it should be Often you don't actually want some things done at compile time although they could be done. It can lead to, e.g., excessive executable sizes, excessive compile times. If you've ever considered using `-ftemplate-depth` in C++, you've probably encountered such a case. Maybe it sounds like I'm splitting hairs and you would say "of course in such crazy cases it's not true", but if you look at C++ projects and what can be done at compile time with modern C++, you would find it's not rare at all.

tomjakubowski 2y ago
Yes. My attitude earlier in my life as a programmer was that moving as much as possible to "compile time" was a universal good. The truth is of course, like everything, there are trade offs. I once worked on an Elixir application whose configuration was accessed almost exclusively at compile time. This was done with the well-intended notion that saving runtime cycles was a good thing. It meant that changing any config (e.g.: "name of s3 bucket") meant recompiling the entire application. It also meant we had to wait for a full application rebuild in CI to deploy fixes for simple configuration errors. Not so super.

trealira 2y ago

One reason you might want an explicit keyword is so that it fails to compile if it can't be calculated at compile time, which is what was intended, rather than fall back to calculating it at runtime. It also seems useful as an ad-hoc method of annotating pure functions; those functions are guaranteed not to modify global variables at runtime or do I/O.

Svoka 2y ago
I guess so... This is reason for `consteval` and such.

samatman 2y ago

The comptime keyword is only needed in Zig if the code could execute at runtime. It forces compile-time evaluation, but it isn't the only way for it to happen. So Zig actually does what you seem to think it should do (and I agree! it's great!): if something can be calculated at compile time, it is. Only when the compiler can't statically deduce a compile-time construct is it necessary to use the `comptime` keyword: in fact, it's an error to use the keyword when the context is already comptime.