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