[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 #14 from ag0aep6g at gmail.com ---
(In reply to Steven Schveighoffer from comment #12)
> 3) Changing the compiler potentially introduces new issues. Changing the
> docs does not.

(In reply to Steven Schveighoffer from comment #13)
> changing the compiler when the existing code works JUST FINE as long as it's
> properly understood and documented seems like a horrible idea to me.

Ok, I guess we just disagree on this. I don't think we should shy away from
fixing issues properly (<- just my opinion) because the code is so fragile that
every touch could break stuff elsewhere.

> It would be a different story if it was not possible to properly initialize
> a static array using the TypeInfo.

It's possible, but even when documented, `initializer`'s behavior is
surprising. I.e., it's likely to be missed/forgotten, bug-prone.

> The current code also returns an array that is null, but with a non-zero
> length when the initializer would otherwise be all zeros to save on binary
> space. That's a weird behavior, but somehow we live just fine with that. I
> don't see why we can't document the other weird, yet legitimate, behavior.

In no particular order:

1) That's documented. Yes, I know, we would make the other weirdness
documented, too. But it isn't yet, so we an opportunity to do it differently,
whereas the all-zeroes ship has sailed. If all-zeroes were undocumented today,
I'm not sure what way of dealing with it I would prefer.

2) All-zeroes is the same for all types. You don't have to check for one
specific kind of type, and then handle the result of `initializer` differently.
You have to check all return values of `initializer` equally. That's
significantly more consistent. It fails way earlier.

By the way, I would say that TypeInfo_StaticArray.initializer violates
substitutability when it behaves differently from the others. Documenting it on
the base class that a derived class behaves differently just makes it a
substitutability violation that we try to handwave our way out of.

3) The point is basically: "We already have one corner case, let's add one
more." I don't think that's the way to go. Minimizing the number corner cases
should be the goal.

Overall, having `initializer` return an array seems like a bad design decision,
since we try to bend/break it whenever the result consists of repeated values.
Maybe we should come up with something that handles repetitive cases more
gracefully, and then get rid of `initializer` (slowly with a full deprecation
cycle, of course).

--