[swift-evolution] removeFirst, optional equiviliant

Rod Brown rodney.brown6 at icloud.com
Wed Jan 6 15:51:12 CST 2016


Having the migrator add a ! will result in consistent behaviour with current code.

The only issue here is that by adding in !, it somehow might suggest to someone reading the code "hey, the writer though about this and is sure it's safe" but really, they should have been checking it anyway currently, and at least someone can *see* their error...

- Rod

> On 7 Jan 2016, at 8:33 AM, Jacob Bandes-Storch <jtbandes at gmail.com> wrote:
> 
> 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?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160107/8c393d7f/attachment.html>


More information about the swift-evolution mailing list