3 ms·

> I do not understand your criticism of [N]. This gives compiler more information and catches errors. This is a good thing! It only does sane thing in GCC, in

> I do not understand your criticism of [N]. This gives compiler more information and catches errors. This is a good thing! It only does sane thing in GCC, in other compilers it does nothing and since it's very underspec'd it's rarely used in any C projects. It's shame Dennis's fat pointers / slices proposal was not accepted. > warrant the additional complexity IMHO In zig case the comptime reduces complexity, because it is simply zig. It's used to implement generics, you can call zig code compile time, create and return types. This old talk from andrew really hammers in how zig is evolution of C: https://www.youtube.com/watch?v=Gv2I7qTux7g https://www.youtube.com/watch?v=Gv2I7qTux7g

uecker 1y ago
Then the right thing would be to complain about those other compilers. I agree that Dennis' fat pointer proposal was good. Also in Zig it does not reduce complexity but adds to it by creating an distinction between compile time and run-time. It is only lower complexity by comparing to other implementations of generic which are even worse.
- Cloudef 1y ago
  Sure there's tradeoffs for everything, but if I had to choose between macros, templates, or zig's comptime, I'd take the comptime any time.
  - uecker 1y ago
    To each their own, I guess. I still find C to be so much cleaner than all the languages that attempt to replace it, I can not possibly see any of them as a future language for me. And it turns out that it is possible to fix issues in C if one is patient enough. Nowadays I would write this with a span type: https://godbolt.org/z/nvqf6eoK7 https://godbolt.org/z/nvqf6eoK7 which is safe and gives good code. update: clang is even a bit nicer https://godbolt.org/z/b99s1rMzh https://godbolt.org/z/b99s1rMzh although both compile it to a constant if the other argument is known at compile time. In light of this, the Zig solution does not impress me much: https://godbolt.org/z/1dacacfzc https://godbolt.org/z/1dacacfzc
- pjmlp 1y ago
  Not only it was a good proposal, since 1990 that WG14 has not done anything else into that sense, and doesn't look like it ever will.
  - uecker 1y ago
    Let's see. We have a relatively concrete plan to add dependent structure types to C2Y: struct foo { size_t n; char (buf)[.n]; }; Once we have this, the wide pointer could just be introduced as syntactic sugar for this. char (buf)[:] = .. Personally, I would want the dependent structure type first as it is more powerful and low-level with no need to decide on a new ABI.
    - int_19h 1y ago
      This feels like such a massive overkill complexity-wise for something so basic.
      - uecker 1y ago
        Why do you think so? The wide pointers are syntactic sugar on top of it, so from an implementation point of view not really simpler.
    - pjmlp 1y ago
      Thanks, interesting to see how it will turn out.
- pron 1y ago
  C also creates a distinction between compile-time and run-time, which is more arcane and complicated than that of Zig's, and your code uses it, too: macros (and other pre-processor programming). And there are other distinctions that are more subtle, such as whether the source of a target function is available to the caller's compilation unit or not, static or not etc.. C only seems cleaner and simpler if you already know it well.
  - uecker 1y ago
    My point is not about whether compile-time programming is simpler in C or in Zig, but that is in most cases the wrong solution. My example is also not about compile time programming (and does not use macro: https://godbolt.org/z/Mc6M9dK4M https://godbolt.org/z/Mc6M9dK4M), but about letting the optimizer do its job. The end result is then leaner than attempting to write a complicated compile time solution - I would argue.
    - pyrolistical 1y ago
      Right tool for the job. There was no comptime problem shown in the blog. But if there were zig would prob be simpler since it uses one language that seamlessly weaves comptime and runtime together
      - uecker 1y ago
        I don't know, to me it seems the blog tries to make the case that comptime is useful for low-level optimization: "Is this not amazing? We just used comptime to make a function which compares a string against "Hello!\n", and the assembly will run much faster than the naive comparison function. It's unfortunately still not perfect." But it turns out that a C compiler will give you the "perfect" code directly while the comptime Zig version is fairly complicated. You can argue that this was just a bad example and that there are other examples where comptime makes more sense. The thing is, about two decades ago I was similarly excited about expression-template libraries for very similar reasons. So I can fully understand how the idea of "seamlessly weaves comptime and runtime together" can appear cool. I just realized at some point that it isn't actually all that useful.

uecker 1y ago

Then the right thing would be to complain about those other compilers. I agree that Dennis' fat pointer proposal was good. Also in Zig it does not reduce complexity but adds to it by creating an distinction between compile time and run-time. It is only lower complexity by comparing to other implementations of generic which are even worse.

Cloudef 1y ago
Sure there's tradeoffs for everything, but if I had to choose between macros, templates, or zig's comptime, I'd take the comptime any time.
- uecker 1y ago
  To each their own, I guess. I still find C to be so much cleaner than all the languages that attempt to replace it, I can not possibly see any of them as a future language for me. And it turns out that it is possible to fix issues in C if one is patient enough. Nowadays I would write this with a span type: https://godbolt.org/z/nvqf6eoK7 https://godbolt.org/z/nvqf6eoK7 which is safe and gives good code. update: clang is even a bit nicer https://godbolt.org/z/b99s1rMzh https://godbolt.org/z/b99s1rMzh although both compile it to a constant if the other argument is known at compile time. In light of this, the Zig solution does not impress me much: https://godbolt.org/z/1dacacfzc https://godbolt.org/z/1dacacfzc
pjmlp 1y ago
Not only it was a good proposal, since 1990 that WG14 has not done anything else into that sense, and doesn't look like it ever will.
- uecker 1y ago
  Let's see. We have a relatively concrete plan to add dependent structure types to C2Y: struct foo { size_t n; char (buf)[.n]; }; Once we have this, the wide pointer could just be introduced as syntactic sugar for this. char (buf)[:] = .. Personally, I would want the dependent structure type first as it is more powerful and low-level with no need to decide on a new ABI.
  - int_19h 1y ago
    This feels like such a massive overkill complexity-wise for something so basic.
    - uecker 1y ago
      Why do you think so? The wide pointers are syntactic sugar on top of it, so from an implementation point of view not really simpler.
  - pjmlp 1y ago
    Thanks, interesting to see how it will turn out.
pron 1y ago
C also creates a distinction between compile-time and run-time, which is more arcane and complicated than that of Zig's, and your code uses it, too: macros (and other pre-processor programming). And there are other distinctions that are more subtle, such as whether the source of a target function is available to the caller's compilation unit or not, static or not etc.. C only seems cleaner and simpler if you already know it well.
- uecker 1y ago
  My point is not about whether compile-time programming is simpler in C or in Zig, but that is in most cases the wrong solution. My example is also not about compile time programming (and does not use macro: https://godbolt.org/z/Mc6M9dK4M https://godbolt.org/z/Mc6M9dK4M), but about letting the optimizer do its job. The end result is then leaner than attempting to write a complicated compile time solution - I would argue.
  - pyrolistical 1y ago
    Right tool for the job. There was no comptime problem shown in the blog. But if there were zig would prob be simpler since it uses one language that seamlessly weaves comptime and runtime together
    - uecker 1y ago
      I don't know, to me it seems the blog tries to make the case that comptime is useful for low-level optimization: "Is this not amazing? We just used comptime to make a function which compares a string against "Hello!\n", and the assembly will run much faster than the naive comparison function. It's unfortunately still not perfect." But it turns out that a C compiler will give you the "perfect" code directly while the comptime Zig version is fairly complicated. You can argue that this was just a bad example and that there are other examples where comptime makes more sense. The thing is, about two decades ago I was similarly excited about expression-template libraries for very similar reasons. So I can fully understand how the idea of "seamlessly weaves comptime and runtime together" can appear cool. I just realized at some point that it isn't actually all that useful.