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 <
[email protected]> wrote:
>
> > On Jun 10, 2016, at 7:43 PM, Dave Abrahams via swift-evolution <
> [email protected]> wrote:
> >
> > on Thu Jun 09 2016, Saagar Jha <[email protected]> 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
> [email protected]
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
--
-Saagar Jha
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
