[Issue 16394] TypeInfo.init() for static arrays returns single element instead of whole array

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=16394

--- Comment #5 from Eyal <eyal at weka.io> ---
I disagree, a function which has subtle corner cases that cause cryptic bugs is
never a "documentation issue". Maybe if it were called "unsafe_init_val" --
you'd know that documentation is crucial here. Otherwise you go on your merry
way until you explode.

I've seen only 2 uses of the init value on generic types, in our production
code and in std.lib.algorithm:initailizeAll.  *Both of these cases* had
cryptic, terrible bugs due to this behavior of typeid(T).init!  If D's standard
library can't get the use of typeid().init right, is it a legitimate function
to expose?

> > Additionally, x = x.init  would work without blowing up the stack when x is
> > large, and then accessing typeid() would be unnecessary.

> I'm not sure what this means.

The only reason we need to use typeid(x).init() is because we cannot really do:

  x = x.init; 

The reason is that this kind of assignment always goes through a stack
allocation. When x.init is a large value, it unnecessarily allocates a huge
chunk of stack. Our stacks are of limited size (fibers). This explodes.

So we work around it using typeid(x).init() and explicit memory copies (similar
to what initializeAll does).

If the compiler had properly implemented x = x.init without superfluous huge
stack allocations, we'd have no trouble because we wouldn't need to use
typeid().init() in the first place (though perhaps this is an LDC-specific
problem)

--