[swift-evolution] Change default compiler fix for not-unwrapped Optional from ! To ?
Erica Sadun
erica at ericasadun.com
Fri Jul 14 13:33:09 CDT 2017
> On Jul 14, 2017, at 2:11 AM, Víctor Pimentel via swift-evolution <swift-evolution at swift.org> wrote:
>
>> On 14 Jul 2017, at 08:05, Rod Brown via swift-evolution <swift-evolution at swift.org> wrote:
>>
>>
>>
>>> On 14 Jul 2017, at 2:36 pm, Robert Bennett via swift-evolution <swift-evolution at swift.org> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170714/04b82fa0/attachment.html>
More information about the swift-evolution
mailing list