[swift-evolution] Optional safe subscripting for arrays
David Sweeris
davesweeris at mac.com
Sun Jan 31 17:21:38 CST 2016
My recollection from the discussion thread is that we didn't really reach a firm consensus on the setter semantics, mostly because Swift doesn't support setter-only subscripts, and we couldn't come up with one argument label that both read well as both a setter & a getter, *and* clearly meant that the assignment itself could fail.
Don't misunderstand me... I'm definitely +1 on this, I'm just not a fan of "ifExists" (no, I don't have any better ideas)
- Dave Sweeris
> On Jan 31, 2016, at 15:07, Maximilian Hünenberger via swift-evolution <swift-evolution at swift.org> wrote:
>
> The setter of the subscript should be:
>
> set {
> if self.indices ~= index && newValue != nil {
> self[index] = newValue!
> }
> }
>
> Since "newValue" is of type "Element?".
>
> It seems that this subscript could also be added to "CollectionType" and "MutableCollectionType".
>
> The setter is weird because you can use an optional element:
>
> var arr = [1]
> // is valid but doesn't set the first element
> arr[ifExists: 0] = nil
>
> var arr2: [Int?] = [1]
> arr2[ifExists: 0] = nil // changes nothing
> arr2[ifExists: 0] = .Some(nil) // sets first element to nil : arr2 == [nil]
>
> I don't know whether a setter should be added at all.
>
> - Maximilian
>
>> Am 31.01.2016 um 23:38 schrieb Rudolf Adamkovič via swift-evolution <swift-evolution at swift.org>:
>>
>> All right, I put together a proposal:
>>
>> https://github.com/salutis/swift-evolution/blob/master/proposals/XXXX-runtime-safe-array-subscripting.md
>>
>> … and opened a PR:
>>
>> https://github.com/apple/swift-evolution/pull/133
>>
>> Let’s see how this goes.
>>
>> R+
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160131/26def0ac/attachment.html>
More information about the swift-evolution
mailing list