My bad, should have phrased my response better :^) Under what circumstances would you need to be able to assign elements in an array out of order, while also requiring Array size/performance? (Genuinely curious, not trying to attack).
IMO, if the differences between Array and Dictionary would cause that much of an issue for your implementation, my guess is you have more important priorities than the need to assign elements out-of-order đ I don't think we'd need to add another type to the standard library for this use case. > On Apr 16, 2017, at 11:22 AM, Saagar Jha <saa...@saagarjha.com> wrote: > > 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 >>> <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. >> >> 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 >> <swift-evolution@swift.org> 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 >>> swift-evolution@swift.org >>> https://lists.swift.org/mailman/listinfo/swift-evolution >> _______________________________________________ >> swift-evolution mailing list >> swift-evolution@swift.org >> https://lists.swift.org/mailman/listinfo/swift-evolution >
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
