A Dictionary uses a lot more space than an Array, though, and allow for bogus keys like “-1”, etc.
Saagar Jha > On Apr 16, 2017, at 10:34, Riley Testut via swift-evolution > <[email protected]> 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. > > Wouldn't the same functionality be accomplished by a Dictionary with Int as > the key type? > > On Apr 14, 2017, at 10:00 AM, Karl Wagner via swift-evolution > <[email protected] <mailto:[email protected]>> wrote: > >>> I'd actually say the #1 reason not to add this feature is that a lot of >>> developers don't seem to understand this, and they're likely to use the >>> feature to make their code try to continue in the face of programmer error >>> instead of trapping like it properly should. A program in an inconsistent >>> state is dangerous; best to stop it quickly before it does some damage.) >> >> Right, so I think the reason is actually that a lot of developers don’t >> understand what an Array is. There are two use-cases for an Array: >> >> 1) As a string of items, don’t care about the length. The maximum prior >> knowledge you can have is that the order may or may not be significant. This >> includes operations like iteration, mapping, reducing and filtering. >> 2) As a string of items of specific length. You have prior knowledge about >> what you expect to find at each location. This includes operations like >> random-access subscripting, which is what we’re talking about. >> >> Basically, the interesting part of a statement such as “let someValue = >> myArray[2]” is: why index 2? What’s so special about that element; why >> couldn't someValue be the item at any index N instead? It’s because we know >> to expect something of special significance at index 2. >> >> In that case, the only time myArray[2] will fail is when your prior >> knowledge breaks down. The type-system has no way to encode and check for >> the length of an Array, and that has allowed somebody to pass in a bad >> value. So what to do? >> >> A) If you absolutely require a value for myArray[2]: Insert a precondition >> check. >> B) If you can still continue without myArray[2]: Check the length of the >> Array. Your logic will be branching anyway in this case, to account for the >> value (and subsequent values) being/not being present. >> >> >> 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. >> >> - Karl >> _______________________________________________ >> swift-evolution mailing list >> [email protected] <mailto:[email protected]> >> https://lists.swift.org/mailman/listinfo/swift-evolution >> <https://lists.swift.org/mailman/listinfo/swift-evolution> > _______________________________________________ > swift-evolution mailing list > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
