Dynamic programming comes to mind. Saagar Jha
> On Apr 16, 2017, at 19:33, Riley Testut <rileytes...@gmail.com> wrote: > > 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 > <mailto: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 <mailto: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 <mailto: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 <mailto:swift-evolution@swift.org> >>>> https://lists.swift.org/mailman/listinfo/swift-evolution >>>> <https://lists.swift.org/mailman/listinfo/swift-evolution> >>> _______________________________________________ >>> swift-evolution mailing list >>> swift-evolution@swift.org <mailto:swift-evolution@swift.org> >>> https://lists.swift.org/mailman/listinfo/swift-evolution >>> <https://lists.swift.org/mailman/listinfo/swift-evolution> >>
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
