[swift-evolution] removeFirst, optional equiviliant

[Rod Brown]

You make a fair point. I would agree the risk is far higher, to be honest. At least returning an optional forces you to do something about the fact it might not have happened, even if it's only to use the ! force unwrapper.

Also of note, as of OS X 10.7, removeLastObject for example on NSMutableArray no longer creates a range exception, and instead simply returns nil.

Perhaps we need to treat these methods as conveniences, and as such subscripting still gets range exceptions, but removeFirst, removeLast etc should get optional return types and no fail if it's empty?

> On 7 Jan 2016, at 8:20 AM, Jacob Bandes-Storch <jtbandes at gmail.com> wrote:
> 
>> On Wed, Jan 6, 2016 at 1:15 PM, Rod Brown via swift-evolution <swift-evolution at swift.org> wrote:
>> You wouldn't ever need for it to be non optional as it simply could be unwrapped with !
>> 
>> That said, there is a decent risk that developers might often get into a habit of forcibly unwrapping the value when the are removing items from arrays where they expect it to have content and it unexpectedly doesn't.
> 
> Isn't there exactly the same risk with removeFirst() as it exists today? Arguably even riskier, because there's no "!" to warn you that it might crash?
>  
>> I think in regards to arrays, there is a decent history of user/dev responsibility to run those checks, and if you don't, there is an out of bounds exception. The check is simply your responsibility. This is designed to promote you to maintain awareness about how many items are in the array at all times, as mismanaged arrays are a cesspool of bugs. If we go through and put an optional here, wouldn't it make sense to make the return values of subscripting also optional? I think this is an all-or-nothing thing.
>> 
>>> On 7 Jan 2016, at 6:12 AM, James Campbell via swift-evolution <swift-evolution at swift.org> wrote:
>>> 
>>> I personally would love to have it as optional behaviour. Not sure when you would ever need it to be non optional ? 
>>> 
>>>> On Wed, Jan 6, 2016 at 6:54 PM, Max Moiseev <moiseev at apple.com> wrote:
>>>> Ahhh, right.
>>>> 
>>>> I believe the thinking here is that since this is an avoidable error, it should be handled in the client code with an `if !array.isEmpty { … }`), leaving errors to really exceptional and unexpected conditions.
>>>> Using optional here will serve the same purpose, IMHO, but instead of preventing the condition, one would have to react to the consequences later. Moreover the type will now be Optional<Element> and it would also be really tempting to write something like `array.removeFirst()!` and have the same trapping behavior.
>>>> 
>>>> Dave, Dmitri, please correct me if I’m wrong.
>>>> 
>>>> max
>>>> 
>>>>> On Jan 6, 2016, at 10:34 AM, James Campbell <james at supmenow.com> wrote:
>>>>> 
>>>>> What I mean't is it would be great is if it was a native swift error :) so we could use try? syntax.
>>>>> 
>>>>> On Wed, Jan 6, 2016 at 6:32 PM, Max Moiseev <moiseev at apple.com> wrote:
>>>>>> Hi James,
>>>>>> 
>>>>>> I believe this code already handles empty array scenario by failing if the precondition is not met.
>>>>>> Or do you have something else in mind?
>>>>>> 
>>>>>> max
>>>>>> 
>>>>>>> On Jan 6, 2016, at 9:36 AM, James Campbell via swift-evolution <swift-evolution at swift.org> wrote:
>>>>>>> 
>>>>>>> If you call removeFirst and the array is empty it would be great if it was optional so it could return nil or at least it threw an error so you could handle that case.
>>>>>>> 
>>>>>>> -- 
>>>>>>>  Wizard
>>>>>>> james at supmenow.com
>>>>>>> +44 7523 279 698
>>>>>>>  _______________________________________________
>>>>>>> swift-evolution mailing list
>>>>>>> swift-evolution at swift.org
>>>>>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>>>> 
>>>>> 
>>>>> 
>>>>> -- 
>>>>>  Wizard
>>>>> james at supmenow.com
>>>>> +44 7523 279 698
>>> 
>>> 
>>> 
>>> -- 
>>>  Wizard
>>> james at supmenow.com
>>> +44 7523 279 698
>>> 
>>> _______________________________________________
>>> 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
> 
> Jacob
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160107/66f2a0b7/attachment.html>