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

[Luis Henrique B. Sousa]

Yes, Rob, even though our proposals are very related, I do think that yours
would fit better in a new proposal.

My first draft was also in regards to change the default behaviour - not
focused on optionals though. It went through a discussion about *masking*
the current fail fast behaviour (e.g. debugging would be more difficult,
could lead to some unexpected bugs, etc) so that we have changed it to
propose those additional subscript methods instead.

On the other hand, your proposal seems to be more consistent with the
existing *problem* and I think it should follow the path I had tried
initially, and hopefully it will get accepted. Considering my python/ruby
background, I really think we need more handy and lenient operations over
collections.

Let's keep the discussion going, but so far I am +1 for that initial idea.

- Luis


On Mon, Jun 6, 2016 at 7:02 PM, Rob Norback <rnorback at gmail.com> 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.
>
> 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>
> 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> 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
>>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>>>
>>>> _______________________________________________
>>> 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/20160606/faab646c/attachment.html>