Blogpost about the T.init problem

[FeepingCreature]

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.