> On Jul 13, 2017, at 7:32 PM, Daryle Walker <[email protected]> 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).
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. — Daryle Walker Mac, Internet, and Video Game Junkie darylew AT mac DOT com
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
