on Mon Apr 17 2017, Karl Wagner <swift-evolution@swift.org> wrote: >> On 17 Apr 2017, at 18:35, Dave Abrahams via swift-evolution >> <swift-evolution@swift.org> wrote: >> >> >> on Fri Apr 14 2017, Karl Wagner <swift-evolution@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@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 _______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution