[swift-evolution] Swift null safety questions

[Elijah Johnson]

Correct me if I am wrong, but it seems like the main intended use of
optionals would be to work with legacy Obj-C code that is missing
nullability specifiers. In the rest of the cases, a forced-unwrap is just
"syntactic sugar" for a fatal error block or a way to indicate that you
have already checked the type using "as" or "!= nil" (ie. that they wrote
the code in a non-Swift style and haven't updated it yet - just the perfect
situation for a warning).

Another use is interoperability with "C" code, where the user knows that
the code does not return a "null" pointer but has no way of annotating that
in C. Or with arrays where the result is optional, but never is when the
index is right. Maybe an @allowsForceUnwrap annotation on the function
could silence this warning. Definitely a much more serious a condition that
where the result of the function call goes unused.

A simple condition that a warning is emitted, except when unwrapping
NSObject and its subclasses, or other unsafe operations like UnsafePointer,
should cover all of its non-syntax uses. I think it is fair to say that
developers would want to see the fatalError() written out.

2017-03-07 13:36 GMT-05:00 Elijah Johnson <ejrx7753 at gmail.com>:

> How about the proposal of warnings and/or fix-it for unnecessary use of
> optionals?
>
> It seems to me though, that there aren't too many "necessary" uses for
> forced-unwrapping. Judging from (https://github.com/apple/
> swift-evolution/blob/master/proposals/0054-abolish-iuo.md), it was
> probably added as a way of helping work with Obj-C also.
>
> func test(a:String?) -> String {
>     return a!
> }
>
> is equivelent to
>
> func test(a:String?) -> String {
>     if let a = a {
>          print(a);
>     } else {
>          fatalError();
>     }
> }
>
> I wouldn't remove it at this stage, but to quote (
> https://github.com/apple/swift-evolution/blob/master/commonly_proposed.md),
> it is "favoring terseness over clarity by introducing new magic syntactic
> sugar," ironically adding this very terse and easy syntax for the coding
> style that we do not want to incentivize.
>
> Adding warnings and a fix-it to make the crash explicit would more or less
> be as good as removing forced-unwrap from the language. Just maybe needs
> some clarification of what exactly is a valid use of the force-unwrap.
> Maybe for interop with Obj-C it should be considered "necessary", for
> example.
>
> 2017-03-07 11:54 GMT-05:00 Josh Parmenter <jparmenter at vectorform.com>:
>
>>
>> On Mar 6, 2017, at 7:52 PM, Elijah Johnson via swift-evolution <
>> swift-evolution at swift.org<mailto:swift-evolution at swift.org>> wrote:
>>
>> Says: Fix it: Insert !
>> Should say: Fix it: Use optional binding.
>>
>> I agree with this in general. I tell people that I’m teaching that
>> unwrapping uses ‘!' for a reason. It should scream at you that something is
>> happening that probably needs more careful attention.
>>
>> Best,
>> Josh
>>
>>
>> Joshua Parmenter | Engineering Lead, Apple Technologies
>>
>> T 248 777 7777
>> C 206 437 1551
>> F 248 616 1980
>> www.vectorform.com<http://www.vectorform.com/>
>>
>> Vectorform
>> 2107 Elliott Ave Suite 303
>> Seattle, WA  98121 USA
>>
>> Think Tank. Lab. Studio.
>> We invent digital products and experiences.
>>
>> SEATTLE | DETROIT | NEW YORK | MUNICH | HYDERABAD
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170307/33f880a5/attachment.html>