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

[Saagar Jha]

Sorry, but I’m going to use your use case as an example…hope you don’t take
it personally :)

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 nil, 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 nil.

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 nil, but does not *require* a check to
compile. Basically, what I’m saying is that with an Optional the compiler
*forces* you to check for nil before you try to use a variable shadowing
with a guard (which I don’t really see as easier than explicitly checking
for nil; they’re basically the same number of characters, and this one
looks more Swifty™ to me anyways):

guard let url = url else {
    return
}

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.

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
URL! parameter. As a user, I cannot trust that you have implemented a check
for nil (maybe you forgot) and a runtime crash would be unacceptable
behavior. Thus, I’m obliged to add my own check for nil before passing in
my URL?, which completely negates the benefits of the IUO you have.


On Thu, Jun 30, 2016 at 9:15 PM Charlie Monroe via swift-evolution <
swift-evolution at swift.org> wrote:

> 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
>
> _______________________________________________
> 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/20160705/4e072902/attachment.html>