4 ms·
People complaining about nil haven't thought the problem through. It makes the language way more complicated if variables can't sit in an uninitialized state (w
by SamReidHughes 8y ago
People complaining about nil haven't thought the problem through. It makes the language way more complicated if variables can't sit in an uninitialized state (with a default value of nil or zero instead of random bits). Basic stuff like named return values no longer work. Slices can only contain certain special zeroable types.
The right thing to do is to know statically in your code whether a variable can be nil, or can't. Don't put stupid little nil checks in every function, but maybe do so when storing a field, e.g. to ensure an object holds valid state.
If your biggest problem is surprise nil pointer values, then that's good for you, because they're relatively easy bugs to track down.
- oconnor663 8y ago> Basic stuff like named return values no longer work. If Rust hypothetically wanted to add named return values, I think the way they'd do it is have the compiler check that all codepaths through the function initialize the returns. In general rustc is happy to let you declare uninitialized variables, and even partially initialize them field-by-field, as long as it can prove to itself that everything's fully initialized by the time you read it.
- SamReidHughes 8y agoThis won't work the way Go does it, or else you end up with fiddly little rules about when you're allowed to take addresses of variables and such.