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 <ejrx7...@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 <jparmen...@vectorform.com>: > >> >> On Mar 6, 2017, at 7:52 PM, Elijah Johnson via swift-evolution < >> swift-evolution@swift.org<mailto:swift-evolution@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 >> >> >
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
