I find it useful when dealing with (NS)URLs. I have a project that deals with
URLs an awful lot and it would be incredible pain to deal to check if each URL
is nonnil at call site.
What I do instead is use IUO arguments in methods where I pass the URLs to. The
IUO nicely indicates "This argument should not be nil on most occasions, but
may be under some circumstances." The only thing I need to do at the top of the
method is guard url != nil else { return }.
Sure, I could do this with optional + shadowing original argument var with
guard let url = url else { return }, but I find it easier this way.
> On Jun 30, 2016, at 5:55 PM, J.E. Schotsman via swift-evolution
> <[email protected]> wrote:
>
> The only reason I can think of writing a function with a force-unwrapped
> parameter is overriding an API function with such a signature, as Chris
> mentioned.
>
> If the function actually doesn’t accept nil you might feel obliged to start
> the function with something like
>
> precondition( IUO argument != nil, “this method cannot handle nil”)
>
> in order to at least provide a message rather than just crashing.
>
> As for consistency and symmetry I don’t think the current practice meets
> these criteria.
> In your own code an IUO means “only use if you are sure it’s non-nil” whereas
> in imported APIs it means “enter nil at your own risk”.
> If the unwrap shorthand `if let x!` would be accepted it would mean “if
> unwrap succeeds use as if it’s an IUO instead of an ordinary optional”.
> That would make three shades of weirdness. I like it.
> _______________________________________________
> swift-evolution mailing list
> [email protected]
> https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
