[swift-evolution] [Pitch] Array full proposal
darylew at mac.com
Sun Jul 16 17:21:03 CDT 2017
> On Jul 13, 2017, at 7:32 PM, Daryle Walker <darylew at 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).
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.
Mac, Internet, and Video Game Junkie
darylew AT mac DOT com
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the swift-evolution