4 ms·

Go has a pervasive concept of “default being zero” where people are encouraged to write code so that zero-initialization is valid and reasonable. This means tha

Go has a pervasive concept of “default being zero” where people are encouraged to write code so that zero-initialization is valid and reasonable. This means that, when adding a new public field to a structure, you always make sure that the default value (nil for pointers) is valid and backward compatible with the previous behavior (eg no change in behavior). Rust has a half backed support for default initialization, where you can either mark all fields as default initialized via a macro or none (or you can mark them and add a constructor that only changes some, but then the API is confusing for clients unless default initialization is a valid construction). This means that it’s much more common to write constructors, and being forced to set many fields to 0, empty string, None, ecc. is tedious and factually useless; the provide support (Default macro) is not powerful enough to avoid this, unfortunately. I strongly prefer Go’s approach to default initialization in general, and I think it is orthogonal to non-nullable types (you could have both and save the day). For instance, I don’t see what we lose in Rust by saying that integers auto-initialize to zero unless you name them in the constructor.

masklinn 8y ago
> Rust has a half backed support for default initialization, where you can either mark all fields as default initialized via a macro or none (or you can mark them and add a constructor that only changes some, but then the API is confusing for clients unless default initialization is a valid construction). So it has half-baked support because… you can opt into exactly how Go behaves but it's not foisted upon you? > This means that it’s much more common to write constructors, and being forced to set many fields to 0, empty string, None, ecc. is tedious and factually useless; the provide support (Default macro) is not powerful enough to avoid this, unfortunately. Be the change you want to see in the world and open an RFC for partial defaulting? It's already possible to "fill in" literal struct with `..Default::default()`, if you can defend there being a use-case for it, this would be extendable to filling in default-able fields even without an explicit (and public) Default implementation for the struct. There was an issue on the tracker in the past (https://github.com/rust-lang/rust/issues/42692 https://github.com/rust-lang/rust/issues/42692) but the change is big enough that it would require an RFC, actual design and consensus, but that's the extent of it. Alternatively, build a macro doing that for you. There might already be one but a quick cargo search didn't turn anything up. > I strongly prefer Go’s approach to default initialization in general, and I think it is orthogonal to non-nullable types (you could have both and save the day). How can you have non-nullable fields with a zero value exactly? > For instance, I don’t see what we lose in Rust by saying that integers auto-initialize to zero unless you name them in the constructor. The regularity of the language to start with.

masklinn 8y ago

> Rust has a half backed support for default initialization, where you can either mark all fields as default initialized via a macro or none (or you can mark them and add a constructor that only changes some, but then the API is confusing for clients unless default initialization is a valid construction). So it has half-baked support because… you can opt into exactly how Go behaves but it's not foisted upon you? > This means that it’s much more common to write constructors, and being forced to set many fields to 0, empty string, None, ecc. is tedious and factually useless; the provide support (Default macro) is not powerful enough to avoid this, unfortunately. Be the change you want to see in the world and open an RFC for partial defaulting? It's already possible to "fill in" literal struct with `..Default::default()`, if you can defend there being a use-case for it, this would be extendable to filling in default-able fields even without an explicit (and public) Default implementation for the struct. There was an issue on the tracker in the past (https://github.com/rust-lang/rust/issues/42692 https://github.com/rust-lang/rust/issues/42692) but the change is big enough that it would require an RFC, actual design and consensus, but that's the extent of it. Alternatively, build a macro doing that for you. There might already be one but a quick cargo search didn't turn anything up. > I strongly prefer Go’s approach to default initialization in general, and I think it is orthogonal to non-nullable types (you could have both and save the day). How can you have non-nullable fields with a zero value exactly? > For instance, I don’t see what we lose in Rust by saying that integers auto-initialize to zero unless you name them in the constructor. The regularity of the language to start with.