On Wed, Jan 6, 2016 at 1:15 PM, Rod Brown via swift-evolution < [email protected]> 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 < > [email protected]> 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 <[email protected]> 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 <[email protected]> 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 <[email protected]> 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 < >>> [email protected]> 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 >>> [email protected] >>> +44 7523 279 698 >>> _______________________________________________ >>> swift-evolution mailing list >>> [email protected] >>> https://lists.swift.org/mailman/listinfo/swift-evolution >>> >>> >>> >> >> >> -- >> Wizard >> [email protected] >> +44 7523 279 698 >> >> >> > > > -- > Wizard > [email protected] > +44 7523 279 698 > > _______________________________________________ > swift-evolution mailing list > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution > > > _______________________________________________ > swift-evolution mailing list > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution > > Jacob
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
