[swift-evolution] [Proposal] Remove force unwrapping in function signature.

[Charlie Monroe]

> To use the parameters, the function would have to check for nil anyways, right (or risk a crash at runtime)? If the parameter is changed from an IUO to an Optional, the check for nil simply becomes a shadowing with guard.

And what if the overridden method returns "T!"? It would become T? in the code, while the original API expects a non-nil value. This IMHO adds confusion to the language. As I've mentioned previously, these are examples that you'd get:

func addObject(object: AnyObject?)
func objectAtIndex(index: Int) -> AnyObject?

This is from NSArray, but if you had a similar un-audited API, then created your subclass of this, you'd get something semantically completely different and users of your API would assume you can pass nil to addObject and that objectAtIndex can return nil.

In case of addObject, would you just silently ignore the nil, or would you crash as NSArray would?

Yes, it's unexpected sometimes to find nil coming from these methods, or getting them as arguments, but it's just as unexpected as finding out that your app is crashing because it's accessing index out of bounds.

> 
> Saagar Jha
> 
> 
> 
>> On Jul 20, 2016, at 21:10, Chris Lattner <clattner at apple.com <mailto:clattner at apple.com>> wrote:
>> 
>> 
>>> On Jul 20, 2016, at 5:24 PM, Saagar Jha <saagarjha28 at gmail.com <mailto:saagarjha28 at gmail.com>> wrote:
>>> 
>>> Sorry for the last email…I didn’t see your response.
>>> 
>>> I realize that disallowing IUOs in parameters (but not as properties) is inconsistent, but IUOs for properties make sense: they must be set during initialization, but sometimes this isn’t possible. IUOs make it possible to use the property just as any other non-Optional one, provided the property is set before it is used (see the proposal). This kind of guarantee doesn’t work for function parameters and return values. 
>>> 
>>> As for IUOs for non-audited methods; why can’t they just all use Optional parameters? It should have the same behavior as before, since you can pass in both an Optional as well as a non-Optional even today.
>> 
>> Because an override of an unaudited method has to *use* the parameters.
>> 
>> -Chris
> 
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160721/f22ed37a/attachment.html>