> Hopefully in future Rust will adopt something like Go’s automatic initialisation of all values to zero, or at least have this as an option (or document it better, if it already is an option).
First, thanks for the feedback!
Unfortunately, I don't think this feature will be added to Rust, though. IMO it causes bugs, as accidentally failing to initialize a variable yields a garbage value at runtime. There's no reason that 0 is any more likely to be a valid integer value than 1, or 42, or 0xdeadbeef, and the compiler shouldn't try to guess. And the feature wouldn't work in Rust anyhow due to the lack of null pointers.
However, having an explicit zero value is convenient, and this is what the Zero trait is for. With Rust traits you can overload on the return value, like Haskell, so you can write:
let (emptyr: Room, emptyt: Tile, emptyl: Lev) = Zero::zero();
let mut ls = [ emptyl, ..100 ];
assuming that your types derive Zero (which you can do with #[deriving(Zero)]). In the future it should be:
let (emptyr, emptyt, emptyl) = zero();
let mut ls = [ emptyl, ..100 ];
This could be done by either writing a zero() wrapper in the prelude or allowing static methods to be imported, both of which are probably good ideas.
IMO it causes bugs, as accidentally failing to initialize a variable yields a garbage value at runtime. There's no reason that 0 is any more likely to be a valid integer value than 1, or 42, or 0xdeadbeef, and the compiler shouldn't try to guess.
When a language default is to zero-initialize, it creates a strong cultural impetus within that language's user community to define data structures such that zero initialization is a valid state.
But if the language is taking a hard line against null (rather than e.g. being able to annotate locations as null-accepting as required, or vice versa), zero initialization may not be the right choice. However the combination of a requirement for definite assignment and non-nullability tends to make algorithms involving dynamically allocated arrays awkward to implement.
As alexcrichton points out on that bug, it's already implemented:
rusti> let (a,b,c): (int, uint, float) = std::num::Zero::zero();
rusti> a
0
rusti> b
0
rusti> c
0
(The explicit type annotations of the tuple are purely because of how rusti works, in most cases they can be dropped as they will be inferred from the use of a, b and c.)
I admit this tripped me up for a minute. After blinking a few times, I realized that any object that's difficult to initialize manually is going to be a constructor provided for it anyway. But, see also: the Zero trait Patrick mentioned, which can be derived.
First, thanks for the feedback!
Unfortunately, I don't think this feature will be added to Rust, though. IMO it causes bugs, as accidentally failing to initialize a variable yields a garbage value at runtime. There's no reason that 0 is any more likely to be a valid integer value than 1, or 42, or 0xdeadbeef, and the compiler shouldn't try to guess. And the feature wouldn't work in Rust anyhow due to the lack of null pointers.
However, having an explicit zero value is convenient, and this is what the Zero trait is for. With Rust traits you can overload on the return value, like Haskell, so you can write:
assuming that your types derive Zero (which you can do with #[deriving(Zero)]). In the future it should be: This could be done by either writing a zero() wrapper in the prelude or allowing static methods to be imported, both of which are probably good ideas.