4 ms·

Uncommenting a line for a platform-specific feature isn't really any more difficult than decorating a function, adding a pre-processor gate, or any of the other

Uncommenting a line for a platform-specific feature isn't really any more difficult than decorating a function, adding a pre-processor gate, or any of the other normal ways of doing it.

dilap 4y ago
more difficult maybe maybe not, but the way zig does it is simpler in that it's fewer languages you have to know: you don't have to learn the c preprocessor (c/c++) or about magic +build tags (Go) or whatever; it's just normal conditionals in the same language. you might [reasonably] say you can't care about that kind of simplicity, which is fine; but radical simplicity is definitely one of the major charms of zig. (and you don't use the zig feature by commenting/uncommenting, it's via inspection of the environment/flags in the comptime code.)
- Kwpolska 4y ago
  So how does Zig handle platform-specific stuff that cannot be compiled on other platforms? Is it an `if` resolved at compile time causing the uncompileable code to be unused and disappear after the Zir stage? You don't need a full preprocessor with macros and other evil stuff. Just #define and #ifdef would solve this without allowing wrong code that randomly disappears. And learning and understanding these two directives requires zero mental effort.
  - TUSF 4y ago
    > Is it an `if` resolved at compile time causing the uncompileable code to be unused and disappear after the Zir stage? Yes. It's exactly that, because Zig very aggressively evaluates values that are known at compile time. It's as simple as: if (builtin.os.tag == .linux) { // Everything here only exists if compiling for Linux. } The standard library uses this quite a lot for OS/CPU specific things.
    - dleslie 4y ago
      That's elegant. It's also not so different than a preprocessor gate, or a function attribute.
      - Kwpolska 4y ago
        I don’t agree that it’s elegant. A preprocessor directive or a function attribute makes it more obvious that the code it covers may be valid only in some conditions. On the other hand, if the language optimizes some `if` statements out, you may have invalid code without noticing — and not only in the case of OS-specific code, but possibly also regular code whose `if` condition became a compile-time constant, even unintentionally/temporarily/by mistake.
        wtetzner 4y ago
        I think it’s elegant, but it seems to me that the check shouldn’t be evaluated until after type checking. But I’m probably missing something about the way Zig works.
        insanitybit 4y ago
        I think types are generated via const, so that wouldn't be possible.
        anonymoushn 4y ago
        This won't work because the conditionally-compiled platform-specific code is expected to not typecheck (or to use fields that do not exist, etc.) The same feature is also used for specializing generic containers to specific types (an idea that became famous after the resounding success of std::vector<bool>) so that for example arraylists of u8 expose a Writer but arraylists of f64 do not. Most code that is conditional on T == u8 won't typecheck if T != u8. I guess more generally these features are used for implementing fmt, json encoders and decoders, etc. None of these thing would work if code conditional on the type had to typecheck for all types.
        deleted 4y ago
  - flohofwoe 4y ago
    Zig not having a text-based preprocessor is a feature, not a bug though. From the pov of a multiplatform coder who's used to exclude platform-specific code with #ifdef/#endif, Zig's behaviour is completely logical (because that's the only way it can work without a C-style preprocessor).
    - stephc_int13 4y ago
      Yes, this is the logical way of doing it without preprocessor. At the end of the day, this is pretty equivalent. Not sure if this is a net gain or not. Conditional compilation is needed, moving the feature from the preprocessor stage to a lazy evaluator is probably costlier for the compiler and it might also be costlier for the IDE to highlight active/inactive parts of the code. From the user point of view, this is very close, mostly a cosmetic change.
- dleslie 4y ago
  If you're already concerned with, and developing, platform-specific code then the extra knowledge isn't really that hard to grasp. Moreover, I can grep for preprocessor defines, attributes, and such by name. There's no way to grep a project for code commented out to prevent execution on some platforms.
- dontlaugh 4y ago
  It’s not necessarily simpler than an explicit hygienic macro system or similar, since comptime is a complex feature with surprising consequences. Mostly it moves the complexity around.
  - throwawaymaths 4y ago
    I work in a language with hygienic macros and in zig, and zigs way is simpler and more constrained.

Uncommenting a line for a platform-specific feature isn't really any more difficult than decorating a function, adding a pre-processor gate, or any of the other normal ways of doing it.

dilap 4y ago

more difficult maybe maybe not, but the way zig does it is simpler in that it's fewer languages you have to know: you don't have to learn the c preprocessor (c/c++) or about magic +build tags (Go) or whatever; it's just normal conditionals in the same language. you might [reasonably] say you can't care about that kind of simplicity, which is fine; but radical simplicity is definitely one of the major charms of zig. (and you don't use the zig feature by commenting/uncommenting, it's via inspection of the environment/flags in the comptime code.)

Kwpolska 4y ago
So how does Zig handle platform-specific stuff that cannot be compiled on other platforms? Is it an `if` resolved at compile time causing the uncompileable code to be unused and disappear after the Zir stage? You don't need a full preprocessor with macros and other evil stuff. Just #define and #ifdef would solve this without allowing wrong code that randomly disappears. And learning and understanding these two directives requires zero mental effort.
- TUSF 4y ago
  > Is it an `if` resolved at compile time causing the uncompileable code to be unused and disappear after the Zir stage? Yes. It's exactly that, because Zig very aggressively evaluates values that are known at compile time. It's as simple as: if (builtin.os.tag == .linux) { // Everything here only exists if compiling for Linux. } The standard library uses this quite a lot for OS/CPU specific things.
  - dleslie 4y ago
    That's elegant. It's also not so different than a preprocessor gate, or a function attribute.
    - Kwpolska 4y ago
      I don’t agree that it’s elegant. A preprocessor directive or a function attribute makes it more obvious that the code it covers may be valid only in some conditions. On the other hand, if the language optimizes some `if` statements out, you may have invalid code without noticing — and not only in the case of OS-specific code, but possibly also regular code whose `if` condition became a compile-time constant, even unintentionally/temporarily/by mistake.
      - wtetzner 4y ago
        I think it’s elegant, but it seems to me that the check shouldn’t be evaluated until after type checking. But I’m probably missing something about the way Zig works.
        insanitybit 4y ago
        I think types are generated via const, so that wouldn't be possible.
        anonymoushn 4y ago
        This won't work because the conditionally-compiled platform-specific code is expected to not typecheck (or to use fields that do not exist, etc.) The same feature is also used for specializing generic containers to specific types (an idea that became famous after the resounding success of std::vector<bool>) so that for example arraylists of u8 expose a Writer but arraylists of f64 do not. Most code that is conditional on T == u8 won't typecheck if T != u8. I guess more generally these features are used for implementing fmt, json encoders and decoders, etc. None of these thing would work if code conditional on the type had to typecheck for all types.
        deleted 4y ago
- flohofwoe 4y ago
  Zig not having a text-based preprocessor is a feature, not a bug though. From the pov of a multiplatform coder who's used to exclude platform-specific code with #ifdef/#endif, Zig's behaviour is completely logical (because that's the only way it can work without a C-style preprocessor).
  - stephc_int13 4y ago
    Yes, this is the logical way of doing it without preprocessor. At the end of the day, this is pretty equivalent. Not sure if this is a net gain or not. Conditional compilation is needed, moving the feature from the preprocessor stage to a lazy evaluator is probably costlier for the compiler and it might also be costlier for the IDE to highlight active/inactive parts of the code. From the user point of view, this is very close, mostly a cosmetic change.
dleslie 4y ago
If you're already concerned with, and developing, platform-specific code then the extra knowledge isn't really that hard to grasp. Moreover, I can grep for preprocessor defines, attributes, and such by name. There's no way to grep a project for code commented out to prevent execution on some platforms.
dontlaugh 4y ago
It’s not necessarily simpler than an explicit hygienic macro system or similar, since comptime is a complex feature with surprising consequences. Mostly it moves the complexity around.
- throwawaymaths 4y ago
  I work in a language with hygienic macros and in zig, and zigs way is simpler and more constrained.