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

[Charlie Monroe]

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 <swift-evolution at swift.org> 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
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution