Blogpost about the T.init problem

[Cym13]

On Wednesday, 11 July 2018 at 07:30:59 UTC, FeepingCreature wrote:
> That would work, it's just a really horrible hack and I hate it.

Bastiaan's solution to simply change the default value slipped my 
mind but is really cleaner and in the same line of thought.

> We're constructing a fictitious domain value that passes our 
> invariants while having zero correspondence to the real world, 
> *just to pass our invariants*. It's an obvious sign of a 
> language issue.

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.

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.

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. So I think you do have the option to meet 
your invariants.