[swift-evolution] [Proposal] Remove force unwrapping in function signature.
saagarjha28 at gmail.com
Fri Jul 22 00:42:49 CDT 2016
Ah, I understand now; that’s a good point.
On Wed, Jul 20, 2016 at 9:54 PM Charlie Monroe <charlie at charliemonroe.net>
> 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> wrote:
> On Jul 20, 2016, at 5:24 PM, Saagar Jha <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.
> swift-evolution mailing list
> swift-evolution at swift.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the swift-evolution