<div dir="ltr"><p>Sorry, but I’m going to use your use case as an example…hope you don’t take it personally :)</p>
<p>Basically, your use of IUOs is exactly what I’m trying to avoid. IUOs may have their uses, but in my mind, they don’t (in my mind) indicate “This argument should not be nil on most occasions, but may be under some circumstances.” I think of it as “this can occasionally be <code>nil</code>, but if you shouldn’t have to check for it since I guarantee it will have a value whenever you try to use it”. If you can’t make this guarantee, then you should be using a plain Optional instead to make it explicit that the value you’re trying to use can be <code>nil</code>.</p>
<p>Interpretation of IUO aside, your approach has other issues, for both the author and the user. As an author, putting an IUO in the function signature makes it possible to passing in <code>nil</code>, but does not <em>require</em> a check to compile. Basically, what I’m saying is that with an Optional the compiler <em>forces</em> you to check for <code>nil</code> before you try to use a variable shadowing with a <code>guard</code> (which I don’t really see as easier than explicitly checking for <code>nil</code>; they’re basically the same number of characters, and this one looks more Swifty™ to me anyways):</p>
<pre><code>guard let url = url else {
return
}
</code></pre><p>whereas with IUOs you can easily forget the check and the compiler won’t warn you. This way, it makes it both explicit as well as safe.</p>
<p>Your function also appears unsafe for users, as well. Let’s assume I was using your code for my project as a framework, and I came across your function. Everything’s perfect, it does what I want, until I come across a <code>URL!</code> parameter. As a user, I cannot trust that you have implemented a check for <code>nil</code> (maybe you forgot) and a runtime crash would be unacceptable behavior. Thus, I’m obliged to add my own check for <code>nil</code> before passing in my <code>URL?</code>, which completely negates the benefits of the IUO you have.</p>
<br><br><div class="gmail_quote"><div dir="ltr">On Thu, Jun 30, 2016 at 9:15 PM Charlie Monroe via swift-evolution <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">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.<br>
<br>
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 }.<br>
<br>
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.<br>
<br>
> On Jun 30, 2016, at 5:55 PM, J.E. Schotsman via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>> wrote:<br>
><br>
> 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.<br>
><br>
> If the function actually doesn’t accept nil you might feel obliged to start the function with something like<br>
><br>
> precondition( IUO argument != nil, “this method cannot handle nil”)<br>
><br>
> in order to at least provide a message rather than just crashing.<br>
><br>
> As for consistency and symmetry I don’t think the current practice meets these criteria.<br>
> 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”.<br>
> 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”.<br>
> That would make three shades of weirdness. I like it.<br>
> _______________________________________________<br>
> swift-evolution mailing list<br>
> <a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a><br>
> <a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>
<br>
_______________________________________________<br>
swift-evolution mailing list<br>
<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a><br>
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>
</blockquote></div></div><div dir="ltr">-- <br></div><div data-smartmail="gmail_signature"><div dir="ltr">-Saagar Jha</div></div>