[swift-evolution] removeFirst, optional equiviliant

Jacob Bandes-Storch jtbandes at gmail.com
Wed Jan 6 15:33:15 CST 2016


I'd be in favor of that, although I imagine it would be very challenging to
change the nullability of the return type without wreaking havoc on
thousands of lines of legacy code. Having the migrator add "!" wouldn't be
all that great.

I think there's also precedent in the stdlib for there to be "unsafe"
variants of these things which skip the bounds-check if you really care for
performance reasons: like unsafeUnwrap(), you could have an
unsafeRemoveFirst().

Jacob Bandes-Storch

On Wed, Jan 6, 2016 at 1:30 PM, Rod Brown <rodney.brown6 at icloud.com> wrote:

> 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
>>>> <https://github.com/apple/swift/blob/master/stdlib/public/core/RangeReplaceableCollectionType.swift#L235> 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/20160106/aed6b826/attachment.html>


More information about the swift-evolution mailing list