[swift-evolution] removeFirst, optional equiviliant

[Jacob Bandes-Storch]

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/512c99ed/attachment.html>