On Friday, 13 July 2018 at 01:26:28 UTC, Cym13 wrote:
I'm not sure I understand, that's what T.init is: a fictitious domain value that just happens to be the default value. It doesn't have to have any meaning and shouldn't be used that way. It's just a value until it has a value. If it happens to be conveniently a useful value, all right, but that's not its first goal IIUC.
T.init is a fictitious but valid instance of the type domain, but it isn't necessarily a valid instance of the *data* domain that the value represents; that's why we can @disable this() and invariant in the first place, to impose additional restrictions that are not modeled by the typesystem.
To present things the other way: you are defining constraints on a type while also defining the default value of that type as not meeting these contraints. No matter how you look at it the default value of a type should be a valid value. How is that not an issue with your own code? Just change the default so that it is within the constraints.
It's impossible to have a fixed value that is a valid value of a type that's semantically embedded in a dynamic data structure.
Null will never be a valid class instance.
Furthermore, while changing the default field value directly is less of a hack the solution to redefine init() entirely actually allows you to do things like making sure the struct is registered in a table somewhere.
At which point, not content to ruin our type with invalid "valid" data, we've ruined the rest of our runtime state as well!
So I think you do have the option to meet your invariants.
Sure, at the cost of making them worthless.
