[swift-evolution] [Proposal] Remove force unwrapping in function signature.

[Saagar Jha]

Yes, that’s what I meant. Basically, I see stuff like this:

func tripleForceUnwrapping(aString: String!) -> String {
    return String(byRepeatingString: aString, count: 3)
}

and later users get a crash with this:

let possiblyNilString = someFunctionThatRetunsAnOptional()
tripleForceUnwrapping(possiblyNilString)

even though it compiles fine.

func tripleWithoutUnwrapping(aString: String?) -> String {
    return String(byRepeatingString: aString, count: 3)
}

let possiblyNilString = someFunctionThatRetunsAnOptional()
tripleWithoutUnwrapping(possiblyNilString)

meanwhile, doesn’t compile and forces the user to think “huh, it’s not
compiling because there’s an Optional” and hopefully add a check


On Fri, Jun 10, 2016 at 7:18 PM Paul Cantrell via swift-evolution <
swift-evolution at swift.org> wrote:

>
> > On Jun 10, 2016, at 7:43 PM, Dave Abrahams via swift-evolution <
> swift-evolution at swift.org> wrote:
> >
> > on Thu Jun 09 2016, Saagar Jha <swift-evolution at swift.org> wrote:
> >
> >> Yes, that’s exactly my point. Force unwrapping optionals adds
> >> confusion for new users; all too often I see newcomers ending up with
> >> the assumption that the force unwrapping takes care of the check for
> >> them.
> >
> > ...but, it *does*.
>
> I took Saagar to mean “the assumption that force unwrapping takes care of
> doing the right thing for them so they don’t ever have to think about nil
> at all.” Which is indeed quite common in beginner Swift code.
>
> Sadly, there is no compile-time check for mindfulness.
>
> Cheers, P
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
-- 
-Saagar Jha
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160611/c543ad18/attachment.html>