An intro to Zig's integer casting for C programmers

Safety (of all kinds) is not the only selling point of Rust and Zig, and the fact that Ada also have safety measures doesn't mean that it's instantly an option for me.

For example, I keep seeing people hype about Zig/Rust, for all kinds of reasons; and the way that they present their arguments is very compelling. While I've heard of Ada before, AFAICT the only context in which it is brought up is to downplay hype over Rust/Zig; never as a standalone.

Sounds like a PR problem, mostly.

EDIT: Not to say that there aren't other problems, just saying that this point alone isn't some magic bullet.

I don't like Rust because it gives me memory safety, tons of languages do that. I love Rust because the tradeoffs it gives me worth the switch, and the overall tooling and ecosystem are very well made.

Is there a good compiler that one can install for free?

Are there a few good and comprehensive books / references / guides, available online for free?

If you want something to become popular, give it away. Ideally, push it. At the very least, have a limited free version. Or turn a bling eye to small-time piracy, as many vendors did for a long time. Or make it dead easy to buy it for $10.

(None of the above works for you? Sorry, you have just turned down 99% of kids who might like to tinker with your tech, love it, and then promote it wherever they go. Your tech may be hot and desired in the narrow circle of pros, but it's not going to become popular and win the world.)

Sure, but if you only ever give people safety scissors then you're severely limiting the kinds of things that they can build. You have to let people who know what they are doing be able to do what they need to do, so you have to be able to turn the runtime safety off. Zig can do this at the scope level.

You don't hear about the struggles of using it in practice because the projects you've pointed out are usually confidential.

In my experience MISRA is a much more popular standard for secure programming in the defence industry versus Ada. MISRA is a C standard, and yes, it runs missile systems, Boeing braking systems, you name it.

Ada suffered from its domain, original price of compilers, and the few UNIX vendors that cared to offer compiler like Sun, it was an additional acquisiation on top of UNIX SDK.

Everyone knows that only newbies do coding errors in C, so why spend the extra money? /s

I would love to see something like "Rustlings" for Ada, as I found that was a good way to practice not only writing code, but reading it as well.

I was able to self-teach Haskell and Erlang without any major problems, and even managed to ship applications written in it commercially.

:D

My argument is that if I need that insane speed and safety features have to be off I should actively work for that not the other way around that I should actively work for safety.

Why? Because we forget to do things.

> Another language that does safety like this incredibly well is Ada (Ada/SPARK)

I wanted to learn Ada for a long time. Do you have a guide or tutorial how to get into it?

https://news.ycombinator.com/item?id=19122884 (!)

https://news.ycombinator.com/item?id=19245898 (!!)

https://news.ycombinator.com/item?id=19274244 (!!)

https://news.ycombinator.com/item?id=19274412

https://news.ycombinator.com/item?id=19770405

https://news.ycombinator.com/item?id=20776296

https://news.ycombinator.com/item?id=20934511 (!!) [3]

https://news.ycombinator.com/item?id=20939336 (!!)

https://news.ycombinator.com/item?id=21286061

https://news.ycombinator.com/item?id=21286292

https://news.ycombinator.com/item?id=21435869 (!)

https://news.ycombinator.com/item?id=23609499 (!!)

Already happening with Nim.

But I'd expect a system programmer to know better. When to use release and when to use development mode.

Case in point, rust doesn't catch integer overflows in release build either. Maybe Efficiency is more important than we think?

Maybe because they assume that it's only used for that purpose? You talk about rocket science and you expect people to jump on the bandwagon...

https://en.m.wikipedia.org/wiki/Cluster_(spacecraft)

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.

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.

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

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.

   var x : u8 = 5;

   var x = 5;

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.

I'm not quite sure if I understood you correctly, but in case you propose that integer <-> float conversion should happen implicitly I have to disagree. While implicitly converting from integer to float/double would probably be fine, implicitly converting from float/double to integer sounds like a recipe for headaches: There are just too many options (truncation/ceil/floor/rounding). Even if you decided that some option should be the standard since it makes sense in 90% of all cases (let's say rounding), you now have a difficult-to-find (since it's implicit) footgun ready to cause damage in the remaining 10% of all cases.

Even in that paragraph lies a small surprise waiting to be found (at least for some people): The floating point standard IEEE 754 defines five different rounding modes - two "normal" modes (Round to nearest, ties to even as well as Round to nearest, ties away from zero) and the additional directed ones mentioned above (truncation, ceil, floor). Interestingly, the default rounding mode (Round to nearest, ties to even) is not the one you probably learnt in school (that would be Round to nearest, ties away from zero). In school, you always round up if you end up exactly between two numbers, i.e. round(0.5) = 1, round(1.5) = 2. However, this introduces a small bias that can manifest itself into a real problem, for example if you round many measurements and then calculate the mean. That's why the default floating-point rounding mode will essentially alternate between rounding up and down, i.e. round(0.5) = 0 and round(1.5) = 2.

Most of the time this is not an issue and you really want the default rounding mode, but I hope this example illustrates why hiding the "implementation detail" of converting floating-point numbers to integers might not be a good idea.

By the way, I just looked up the man page for round(), and to my surprise found that it will always round ties away from zero, independently of the floating-point environment. If you want to round using different rounding modes in C, you apparently have to use nearbyint() and friends after setting up the rounding mode using fesetround().

PS: Of course the rounding modes are all about rounding floating-point values, not necessarily converting them to integers, but I think the point should be clear.

I contributed to found the only discrepancy in D vs C code wrt integer (-byte would yield byte instead of int), and it was fixed so that they match exactly C _conventions_.

There was more than enough time to learn why it was the right option to start with.

Or not, you can also choose not to write these kinds of languages and nobody can blame you -- to each their own.

  var x : u8 = 5;
  var y = @as(u32, x);

  var x : u8 = 5;
  var y : u32 = x;

https://www.godbolt.org/z/x8a65sPcr

Like, you saw it in the docs when you were mildly interested and decided it wasn't for you? Or you started a project, had at least a "hello world" compiling, but then eventually gave up on it because you were tired of casting? In that case I'm curious what the project was since I haven't run into casting all that often, but it might vary by domain.