[swift-evolution] [Pitch] Array full proposal

[Daryle Walker]

> 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.

— 
Daryle Walker
Mac, Internet, and Video Game Junkie
darylew AT mac DOT com 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170716/b170a5cd/attachment.html>