Ah, I understand now; that’s a good point. On Wed, Jul 20, 2016 at 9:54 PM Charlie Monroe <[email protected]> wrote:
> 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 <[email protected]> wrote: > > > On Jul 20, 2016, at 5:24 PM, Saagar Jha <[email protected]> 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 > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution > > > -- -Saagar Jha
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
