4 ms·

Even if you never use zig generics --if nothing else eliminating fucking spiral types is enough of a quality of life improvement alone that you should consider

Even if you never use zig generics --if nothing else eliminating fucking spiral types is enough of a quality of life improvement alone that you should consider zig over C. if you've never heard of them: https://c-faq.com/decl/spiral.anderson.html https://c-faq.com/decl/spiral.anderson.html I'm not even sure if the faq is in jest or not.

flohofwoe 3y ago
This "spiral type notation" has been acknowledged in K&R 2nd Edition as one of the less fortunate design decisions in C.
pjmlp 3y ago
Ironically, almost 40 years later Pascal linage of languages finally have their revenge in type declarations.
jstimpfle 3y ago
The clockwise/spiral rule is a misunderstanding, it doesn't exist and C type syntax is not that complicated. The thing that isn't well known about C type syntax is that there is no type syntax. At least originally, there wasn't really type syntax. (This was later muddied by e.g. types in function signature parameters, which came from C++ -- and which are a good thing to be clear). Types follow usage (given as normal code expressions), and if you can read normal expressions, you'll know what a type declaration means. The syntax is simply: type-name EXPR. where type-name is a simple name (or tagged name, such as struct mystruct), and EXPR is a limited subset of normal expressions. Example: int *foo[10]; Read like (type-name = int), (EXPR = *foo[10]). Now, if you now how to understand the EXPR, you'll know what the type of the variable foo is. Since (*foo[10]) must be int, you can simply go backward to know the "shape" of foo. Similarly, there is some elegance how to define a type name instead of a variable -- you simply add the "typedef" keyword and that's it. Even though that idea is a bit arcance admittedly, and not so pure anymore today, now I'm used to the C way of declaring types, and I think I like the fact that there isn't much of an additional syntax. Maybe it even removes mental overhead when reading code.
- throwawaymaths 3y ago
  That's actually a problem. In c, variable declarations are not context-free. mytype *foo; Could be a variable declaration, Or is it? Suppose you had int mytype = 42; int foo = 1; Before it. The C compiler will happily turn the statement into a multiplication with the result going to /dev/null var foo: mytype; Can never be parsed with any other meaning depending on how the chips fall after parsing (and possibly analysis, given that macros are a thing) the entirety of the file.
  - jstimpfle 3y ago
    Yes it comes with its problems. The context sensitivity is annoying and it makes creating good tooling hard. But given macros it doesn't worsen the situation much anyway. For writing a batch parser/compiler that properly reads all the includes too, the context sensitivity is only a theoretical problem. Adding a type table is easy. Not having to type "var" all the time is very nice on the other hand.
    - throwawaymaths 3y ago
      Clarity is always better than saving keystrokes. Code is generally more read than written.
      - jstimpfle 3y ago
        Adding keystrokes is not the same as adding clarity, though.

flohofwoe 3y ago

This "spiral type notation" has been acknowledged in K&R 2nd Edition as one of the less fortunate design decisions in C.

pjmlp 3y ago

Ironically, almost 40 years later Pascal linage of languages finally have their revenge in type declarations.

jstimpfle 3y ago

The clockwise/spiral rule is a misunderstanding, it doesn't exist and C type syntax is not that complicated. The thing that isn't well known about C type syntax is that there is no type syntax. At least originally, there wasn't really type syntax. (This was later muddied by e.g. types in function signature parameters, which came from C++ -- and which are a good thing to be clear). Types follow usage (given as normal code expressions), and if you can read normal expressions, you'll know what a type declaration means. The syntax is simply: type-name EXPR. where type-name is a simple name (or tagged name, such as struct mystruct), and EXPR is a limited subset of normal expressions. Example: int *foo[10]; Read like (type-name = int), (EXPR = *foo[10]). Now, if you now how to understand the EXPR, you'll know what the type of the variable foo is. Since (*foo[10]) must be int, you can simply go backward to know the "shape" of foo. Similarly, there is some elegance how to define a type name instead of a variable -- you simply add the "typedef" keyword and that's it. Even though that idea is a bit arcance admittedly, and not so pure anymore today, now I'm used to the C way of declaring types, and I think I like the fact that there isn't much of an additional syntax. Maybe it even removes mental overhead when reading code.

throwawaymaths 3y ago
That's actually a problem. In c, variable declarations are not context-free. mytype *foo; Could be a variable declaration, Or is it? Suppose you had int mytype = 42; int foo = 1; Before it. The C compiler will happily turn the statement into a multiplication with the result going to /dev/null var foo: mytype; Can never be parsed with any other meaning depending on how the chips fall after parsing (and possibly analysis, given that macros are a thing) the entirety of the file.
- jstimpfle 3y ago
  Yes it comes with its problems. The context sensitivity is annoying and it makes creating good tooling hard. But given macros it doesn't worsen the situation much anyway. For writing a batch parser/compiler that properly reads all the includes too, the context sensitivity is only a theoretical problem. Adding a type table is easy. Not having to type "var" all the time is very nice on the other hand.
  - throwawaymaths 3y ago
    Clarity is always better than saving keystrokes. Code is generally more read than written.
    - jstimpfle 3y ago
      Adding keystrokes is not the same as adding clarity, though.