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

[Saagar Jha]

Ah, I understand now; that’s a good point.

On Wed, Jul 20, 2016 at 9:54 PM Charlie Monroe <charlie at charliemonroe.net>
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 <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.
>
> -Chris
>
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
> --
-Saagar Jha
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160722/d1669bf4/attachment.html>