> On Jul 14, 2017, at 2:11 AM, Víctor Pimentel via swift-evolution > <[email protected]> wrote: > >> On 14 Jul 2017, at 08:05, Rod Brown via swift-evolution >> <[email protected]> wrote: >> >> >> >>> On 14 Jul 2017, at 2:36 pm, Robert Bennett via swift-evolution >>> <[email protected]> wrote: >>> >>> When writing Swift code, it is not uncommon to forget to unwrap optionals. >>> The compiler will offer a fixit, telling you you must insert either a ? or >>> a !. However, when you accept the fixit, ! is inserted (at least, it is for >>> me in Xcode 8.3). >> When you treat an optional as non-optional, the compiler has no way to do a >> fixit that would appropriately handle the optional. Felix made a good >> example. The only direct fixit would be a force unwrap. If you used “?” then >> your non-optional use would turn into an optional and your parameter would >> generally be non-optional. The fixit is just explicitly doing what you >> implicitly expected it to do. >> >>> >>> Ideally the fixit would default to ? because this is the preferred option; >>> ! is often a sign of non-Swifty code and does not interact well with >>> idiomatic Swift constructs such as if-let-(as?), guard-let-(as?)-else, etc. >>> Also I think it’s safe to say that fixits should not err on the side of >>> crashing at runtime. >> >> " ! is often a sign of non-Swifty code “ >> I would strongly challenge this assumption. Many core team members have >> commented about appropriate uses of the ! operator. It shouldn’t be used >> lightly, but it’s there for a reason and it most definitely isn’t >> “non-swifty”. > > I think it's not a farfetched assumption to imply that if the compiler > encounters that code, the programmer didn't realize or remember that they > were dealing with optionals. > > If the compiler suggests to force unwrap that expression, it is also fair to > assume that most inexperience programmers will just apply that fix it. A more > experience programmer can decide whether to force unwrap it or to handle the > nil case in any other way, depending on the context and code style. > > Personally, I'd prefer that the compiler didn't encourage so much to use > force unwrapping, not because I think that it has no use, but because I think > that newbies should not learn that pattern first. > > Surely, if I were new to the language and the compiler kept doing that fix > it, I would think that it's "the way" to deal with optionals. > > What would I prefer? At least, for the fix it to provide several options, > more or less in this order: > > - checked unwrap (if applies) > - if let > - guard let > - force unwrap
Unfortunately, I think `!` *is* the proper fix-it here. The mechanisms to insert conditional binding, for example, are too unwieldy a tool at the many arbitrary places where an optional is used in place of a non-optional. I believe introducing an unwrap-or-die operator in parens (see https://github.com/apple/swift-evolution/pull/729 <https://github.com/apple/swift-evolution/pull/729>) would provide a better fixit: * A sophisticated developer is unlikely to use fix-its as a blunt instrument to make code work. Their use of `!` can be appropriate and, in their hands, unlikely to be fixit-driven. * The unsophisticated developer is better served with `!!`, which self-documents the safety issue and can be further evaluated for refactoring, supporting safer learner patterns. Unlike the other approaches for conditional binding, `!!` is fix-it friendly. -- E
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
