I've been following Nim for a while now (including back when it was called Nimrod), but the big reason I've never dug much more into it is because it repeats the Billion Dollar Mistake[1] of allowing values (yes, not all values, but important ones) to be nil without explicitly using Option types.
It's disappointing that Nim has not (perhaps cannot, for backwards compatibility) learned the same lesson here that most other modern languages have, and used explicit nilability embedded in the type system.
And to preempt the argument that "you can't, for performance reasons!", you could do the same thing as Rust does and explicitly opt-in to having your code break if something is nil, via a call like `.unwrap()` which the compiler may optimize away.
Excellent news! I read the discussion that has since been linked elsewhere, and got the general impression that there wasn't going to be a change for backwards compatibility reasons. Glad to be proven wrong!
the default might not be changed in 1.x, but this shouldn't make it less typesafe: access to nilable types would be checked.
there are also the z3-integration related checks which might even apply to index bounds or eventually other invariants, so this kind of safety is important for Araq and Nim https://nim-lang.org/docs/drnim.html
The real question is: how much of standard libraries and broader ecosystem use them? Scala has null values, but broad usage of Option and Either so I can often write code as if null didn't exist.
Unfortunately, it'd be impossible to work effectively with C code without `nil`. You can create objects set to `not nil`. To be fair, I've had a few points when creating a new type that I forgot to allocate a new instance properly, but option types wouldn't have saved me any work. It would've produced a similar stacktrace. I think the compiler produces a warning, but I'm still working down the warning's lists. You can see more discussion on defaulting not nil here: https://github.com/nim-lang/Nim/issues/6638
Having all references that are returned from C be treated as Option types would resolve this difficulty, no?
Likewise, your type system can prevent you from using uninitialized values in other languages, without the need for Option (and indeed the unwrap() call you imply you would have used) from being needed.
Though yes, I'm glad to see this is being addressed :).
> Having all references that are returned from C be treated as Option types would resolve this difficulty, no?
Perhaps, but there's more than just returns. Dealing with most C code there's a fair bit of pointer passing and manipulation. It's nice being able to deal directly with C code and not have to worry about the impedance mismatch, but still be able to move up the type system. It's more a pragmatic choice.
> Likewise, your type system can prevent you from using uninitialized values in other languages, without the need for Option (and indeed the unwrap() call you imply you would have used) from being needed.
In this case, mostly its just me not using the type system well. :-) But that's the price I pay for a using a flexible language I can readily use in embedded work. NPE's really don't cause me any headaches compared to most of the other aspects of integrating heavily with C code in embedded systems.
Same reason as using unsafe Rust to interface w/ C/C++, to wrap the the unsafe bits and make safer API's asap. Nim's macros also making interactions with C API's safer. To be clear, I'll be glad when Nim checks these things by default (the Z3 checker will be great for that!).
It's disappointing that Nim has not (perhaps cannot, for backwards compatibility) learned the same lesson here that most other modern languages have, and used explicit nilability embedded in the type system.
And to preempt the argument that "you can't, for performance reasons!", you could do the same thing as Rust does and explicitly opt-in to having your code break if something is nil, via a call like `.unwrap()` which the compiler may optimize away.
[1] https://www.infoq.com/presentations/Null-References-The-Bill...