[swift-evolution] Arrays Returning Optionals instead of Index Out of Bounds

Vladimir.S svabox at gmail.com
Tue Jun 7 06:48:21 CDT 2016


On 06.06.2016 21:02, Rob Norback wrote:
> First of all, thank you all for bringing me up to date so quickly.  I
> looked over the proposal and it looks awesome.
>
> But as Chris mentioned, this doesn't solve the expected behavior and
> ambiguity of ```Array<Int?>```
>
> In this case I would expect the default behavior (myArray[4]) without using
> myArray[checking: 4] should return a nil in this case.

As Luis already noted, there was a discussion started with exactly the same 
suggestion : return optional for wrong index/range. During the discussion 
consensus was(I believe so) found that such proposal could not be 
supported. But, as an alternative, special explicit syntax for 
optional/checking results for index/range parameter was suggested. I'd 
recommend to read messages of these discussions.

As for [Int?], I believe we need no any additional solution for this 
special case: you have to check if index is in array's bounds and if it is, 
get value using standard subscript method.

>
> And Chris, I think it would make the most sense to have myArray[0] = nil to
> be stored if the index is in Range, and for myArray[100] = nil to give a
> warning of no assignment being made because index is out of range, kind of
> like an unused variable.  Right now myArray[100] = nil gives you
> EXC_BAD_INSTRUCTION.  Then if you assigned myArray[100] = 200, that would
> have to simply change the Range.
>
> Chris, I honestly have to think more about that ambiguity with dictionaries.
>
> I can see that this would definitely need some further fleshing out, but it
> seems to be sufficiently different from Luis' proposal to perhaps merit
> it's own proposal.
>
> It's up to you Luis, but I think this might be a bit more controversial
> then the changes you've proposed, making it possible for your proposal
> getting rejected.  (I want your proposal accepted, since I would use those
> features today).  Partial acceptance of a proposal doesn't seem to be a
> thing. (Once again please correct me if I'm wrong).
>
> On Mon, Jun 6, 2016 at 11:46 AM Luis Henrique B. Sousa <lshsousa at gmail.com
> <mailto:lshsousa at gmail.com>> wrote:
>
>     Thanks Vladimir,
>
>     The correct link is this one (with the additional min/max operations in
>     the implementation):
>     https://github.com/luish/swift-evolution/blob/proposal-lenient-collection-subscripts/proposals/nnnn-more-lenient-collections-subscripts.md
>
>     Here is the pull request on the swift-evolution
>     repo: https://github.com/apple/swift-evolution/pull/328
>
>     Any help or suggestion to improve the proposal is welcome. :-)
>
>     - Luis
>
>     On Mon, Jun 6, 2016 at 6:10 PM, Vladimir.S via swift-evolution
>     <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>
>         Please find this draft of proposal(hope this is correct link for
>         latest version):
>         https://github.com/luish/swift-evolution/blob/more-lenient-subscripts/proposals/nnnn-more-lenient-collections-subscripts.md
>
>         The main idea is to introduce 2 new subscript methods:  [clamping:]
>         and [checking:]
>
>         There was discussion in "[Proposal] More lenient subscript methods
>         over Collections" and (older) "[Proposal] Safer half-open range
>         operator"
>
>
>         On 06.06.2016 19:50, Rob Norback via swift-evolution wrote:
>
>             Hi Everyone!
>
>             This is my first time emailing the swift evolution list, so if
>             this topic
>             has already been discussed please let me know.  I looked
>             through all the
>             accepted and rejected proposals and it doesn't seem to be on there.
>
>             The main thought is that dictionaries return optionals, so why
>             not arrays?
>             Or other CollectionTypes for that matter.  I would think this
>             would be the
>             expected behavior in this situation:
>
>             var myArray:[String?] = []
>             print(myArray[4])
>             // EXC_BAD_INSTRUCTION, but could just be Optional(nil)
>
>             Then you could do things like
>
>             if let arrayValue = myArray[4] {
>                // do something
>             }
>
>             Of course you could simply check with with the count, but
>             considering
>             Swift's use of optionals to represent empty variables rather
>             than erroring
>             out or returning an empty String, I think this functionality
>             would be
>             appropriate to include in the Swift standard library.
>
>             And there's about 15,000 people who've looked for this
>             functionality in the
>             last year:
>             http://stackoverflow.com/questions/25329186/safe-bounds-checked-array-lookup-in-swift-through-optional-bindings.
>
>             Please let me know what you think.
>
>             Best,
>             Rob Norback
>
>
>             _______________________________________________
>             swift-evolution mailing list
>             swift-evolution at swift.org <mailto:swift-evolution at swift.org>
>             https://lists.swift.org/mailman/listinfo/swift-evolution
>
>         _______________________________________________
>         swift-evolution mailing list
>         swift-evolution at swift.org <mailto:swift-evolution at swift.org>
>         https://lists.swift.org/mailman/listinfo/swift-evolution
>
>


More information about the swift-evolution mailing list