[swift-evolution] [Pitch] Adding safety to arrays

[Dave Abrahams]

on Mon Apr 17 2017, Karl Wagner <swift-evolution at swift.org> wrote:

>> On 17 Apr 2017, at 18:35, Dave Abrahams via swift-evolution <swift-evolution at swift.org> wrote:
>> 
>> 
>> on Fri Apr 14 2017, Karl Wagner <swift-evolution at swift.org> wrote:
>> 
>
>>> Personally, the only valid use-case I can think of is when you want to
>>> initialise an Array’s elements out-of-order - i.e., you want to set a
>>> value for myArray[2] despite myArray[0] and [1] not being
>>> populated. In that case, it would be better to have some kind of
>>> SparseArray type, and for us to have a proper API for unsafe
>>> initialisation of stdlib types.
>> 
>> That is a point in the design space, but there's really no need to
>> expose unsafe initialization in order to get that functionality.  You
>> could simply build ArrayOfOptional<T> that would present the same API as
>> Array<T?> but would use a separate inline buffer of bits to denote which
>> of the optionals were non-nil.
>> 
>> -- 
>> -Dave
>> 
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>
> I wasn’t saying a SparseArray type should be part of the standard
> library, but possibly it’s something which could be added to
> Foundation or some 3rd-party “Common Collections” package.

I think it probably should be.

>
>
> Like all data structures, the most efficient one depends on how well
> you can predict what it will store and how it will be
> accessed/modified. A Dictionary<Integer> might be great for large
> collections that are exceptionally sparse, but it may also be wasteful
> depending on your circumstance.
>
> As for unsafe initialisation, that’s something I badly, badly
> want. 

Me too.  I'm just saying it's an orthogonal concern.

-- 
-Dave