Comment by bvrmn | Hacker News Reader

Comment by bvrmn | Hacker News Reader

Parent Full thread

Yes it is.

1) Most of pointers in real apps are non-nullable and it's nice to have enforcement from a compiler.

2) Good compilers verify you actually check nullable (optional) values have a corresponding check. In particular Zig literally forces you to unwrap value, so no unexpected state.

It's a really amazing QoL.

And no, optionality doesn't make type system any harder. Also C lacks alignment enforcement on type level and it's a real footgun which Zig also fixed. Zig has many warts but this part (optionality, alignment and slices) makes a big difference comparing to C without Rust/C++ level of type acrobatics.

> I also once believe that complex type systems are the answer, but over time I realized this is not really true.

It's suboptimal decision, you load your brain with stuff compiler should resolve for you.

Edit: ahah, just noticed your nick. Really appreciate your work on C improvements. Please ignore my yapping :) I literally know nothing comparing to you.

My worries about coding all these things into type systems is that this freezes the semantics at a time during development where one is still figuring out the ideal semantics.

In any case, I wonder what you think about my experimental maybe type? https://godbolt.org/z/MTdj81841

I like maybe_value dereferences NULL with SIGILL and you have at least a backtrace with exact invalid access position.

Oh, you can get the information at compile time as well. https://godbolt.org/z/hTYbTE8j8 (or https://godbolt.org/z/K1M68sY3Y but this will be tricky in a larger code base)

That's the reason language/compiler should directly support optionality.

You can't fool yourself and have to handle all cases: https://godbolt.org/z/4GqMdPej3

So it seems exactly the same to me?

Nice one. gcc/clang are smart enough to get .ok condition statically. I'm very curios how complex an expression could be.

> My worries about coding all these things into type systems is that this freezes the semantics at a time during development where one is still figuring out the ideal semantics.

I don't get this part at all, especially in a language with static typing. It's completely normal for me to not be sure which type I need here and so I use a type alias, or if I'm even less sure I make a wrapper type so that it only has the properties I choose. So I don't see this "freezing" semantics any more than an identifier name would - we can just change it if we change our minds, no problem.

To give a comparable example from elsewhere, when I'm still feeling out the problem I often write Rust's loop, the infinite loop which is Rust's only primitive looping structure (for and so are just sugar). That doesn't mean I write only weird odd-ball loops, but when I'm not sure the raw infinite loop is fine if I decided to consume all the Widgets in this Vec<Widget> like a for-loop but it's also OK if I decided to index through it, or do something entirely different. Rust's "clippy" will prompt me to write a more idiomatic while-let or for-each loop when I've nailed down the whole thing.

Reply on news.ycombinator.com