Hacker News Reader

Comment by scoutt | Hacker News Reader

I am curious to know the reasons behind the @as() syntax. What's wrong with "i32 y = (i32) x;"?

I look with interest to new languages but after so many years dealing with C, my parser crashes when I see the type after the variable name and at the end of functions declarations.

    var x : u8 = 5;

What's wrong with "u8 x = 5;"?

And I don't really like type inference very much (or when it's abused or cannot be avoided). What is "b"? Oh, I have to check what it's being casted from...

    var a: u8 = 255;
    var b = 1 + 2 + 3 - (4 + @as(i32, a));

What type is "b"? i32?

Curious fact: the above code generates >40000 lines of assembly in godbolt: https://www.godbolt.org/z/fxfbb9jfn

View on HN

> What's wrong with "u8 x = 5;"?

I believe it makes the parser marginally more complicated. Let's say you had a non-builtin type, "foo". The var trigger immediately declares what's going on. For "foo x = 5;" the parser must either 1) have contextual information that foo is a declared type or 2) wait to notice that there are two identifiers side-by-side and then resolve that this means "it must be a variable declaration".

Honestly, C and C++ are very much in the minority for choosing this syntax. Coming form pascal, I remember finding this syntax to be annoying 20 years ago, so it's my bias to believe that this is just internalized pain for C devs.

As for the type coercion with the () operator... well, C is infamous for "spiral types". Typecasting complicated things in C, like, say, an array of pointers, can get scary as hell.

A bit more than marginally more complicated, if you consider the cases of parsing partial or incorrect programs.

You want to be able to (somewhat) parse those so that you can syntax-colour, auto-complete, and mark errors in a code editor.

I think those are the major reasons modern languages don’t do such things the C way.

> I believe it makes the parser marginally more complicated

This would mean that the "peace of mind" of the Zig compiler developer has priority over my own "peace of mind". That's not ok.

Is the compile developer reasoning "I don't care if the syntax is verbose, messy (or whatever), it just makes my job easier"?

> Honestly, C and C++ are very much in the minority for choosing this syntax

Java, C#, Objective-C....

> Curious fact: the above code generates >40000 lines of assembly in godbolt: https://www.godbolt.org/z/fxfbb9jfn

I took a quick glance at the ASM, and it seems that the majority of that is code from the stdlib run prior to main. Compiling with -OReleaseSafe brings that down to 15,000 lines of assembly.

If you get rid of "main" and compile it as an exported function, you get far less code: https://www.godbolt.org/z/jjGP4xsfx

If you add -OReleaseSafe to the "export fn" version I shared, it's around 4 lines of code calling panic. Adding -OReleaseFast, and it's just a ret statement.

> Compiling with -OReleaseSafe brings that down to 15,000 lines of assembly.

I tried it with -OReleaseFast to compare, and it's 500-ish lines. That's amazing.

remove "pub" from your godbolt. Zig/godbolt is identifying that you're trying to build a full program and so it brings in a lot of the boilerplate necessary to launch a program (for example, the panic handler, stdlib stuff to format strings for the panic handler, etc).

On the other hand, leave out “pub” and Zig won’t compile it…

juxtaposition (i.e. syntax that has meaning when two identifiers stand together separated only by whitespace) is generally a problem for parsing. Basically, it introduces all kinds of parsing ambiguities. Compare the following:

    a *b
    a * b
    a[n] x
    b [n]
    a<x> y
    a < x > y
    e(1) f
    e (1)f

Even for C/C++ this is complicated (you need the symbol table when parsing, to know if an identifier is a type or not), but for more advanced languages, it's even worse (e.g. if you support pattern matching / destructuring assignment).

Declaring variables with var let's you also write let or const instead, giving the programmer more options (and making those options obvious as well).

You might not "like" type inference, but it really is superior to no-type-inference - you can always also write the expected type, if you want.

> you can always also write the expected type, if you want.

But you have to read the code of people who didn‘t.

Exactly. Like when you see:

    var x = some_function();

What am I dealing with here? mmmmmm....

Ok... let's find some_function()... I hope my editor has "go to definition", otherwise "grep -r some_function ."...

   var x : u8 = 5;

allows making type optional while keeping the code about the same, e.g.

   var x = 5;

This arrangement has this nice consistency to it, with the type info being more of a hint (to the compiler or to the programmer) than a required component.

> I am curious to know the reasons behind the @as() syntax. What's wrong with "i32 y = (i32) x;"?

Built-ins in Zig are functions beginning with `@`. Your cast operator would be a new syntax construct, something Zig tries to limit as much as possible (keeping the parser simple).

> What type is "b"? i32?

That's easy, i32. Integer literals are of type comptime_int, which may coerce into other integer types if possible without loss of information, and since the only typed expression is the @as, every other integer in the line will coerce to its type.

> That's easy.

For code that is not yours, or code that you open a year later, I think it's easier to specify the type. Exactly as when you see something like "var x = some_function();" and you need to know the type.

Best practice for languages with this "var" approach is to use it when the type is obvious or irrelevant and to explicitly declare the type when it is non-obvious and relevant.

If you are reviewing code and can't instantly tell what the type is for a variable, ask the author to explicitly include the type. Problem solved.

You can also use `@compileLog(@TypeOf(some_function))` or the same for the result. Type inference mostly makes it easier to change the types involved without having to update every single variable binding which would often be rather error prone in languages with implicit casts.

The other gain here is with duck-typing as being less explicit allows you to write more generic code which will often do what you want as long as the shape fits without `void*` which gives up on type safety.

Zig uses @something everywhere, maybe they just like Objective-C.

Reply on news.ycombinator.com