In a response to that separate post, I chose run-time DI for local objects and stored instance properties (the checks happen within each designated initializer), and one-shot initialization otherwise.
···
On Jul 13, 2017, at 7:32 PM, Daryle Walker <darylew@mac.com> wrote:
3) Default initialization semantics for arrays including a DI exception for fixed-length arrays that aren’t fully initialized
My first thought was full initialization, like other objects, but someone on the list really wanted a way to not have full initialization. I could see his point; filling in a bunch of zeros for a large array for math purposes could get expensive, especially if the values are immediately ran over. Even if we make closure-initialization return non-optionals, we still have to worry when an array is filled by a loop that gets exited early.
As long as you have this magical type, you should probably give it some magical methods. A “backfill” initializer, perhaps. We cannot break DI just because it’s syntactically inconvenient.
There’s already the “default” term in extended array literals. And the “func” term allows the elements to be determined via closure.
For DI, it’s worse than you think, which is why I put out a separate post on this issue. DI assumes one sub-declaration per sub-object; the raison de-tere for arrays is to defeat this assumption. DI and FSAs are fundamentally incompatible; something has to break (forced initialization on declaration, static array indexing, run-time DI, or undefined behavior on possible uninitialized reads).
—
Daryle Walker
Mac, Internet, and Video Game Junkie
darylew AT mac DOT com