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

[Saagar Jha]

(Comments inline)
Saagar Jha



> On Jul 20, 2016, at 16:47, Saagar Jha <saagarjha28 at gmail.com> wrote:
> 
> 
> 
> On Wed, Jul 20, 2016 at 12:52 PM Chris Lattner <clattner at apple.com <mailto:clattner at apple.com>> wrote:
> On Jul 19, 2016, at 3:46 PM, Saagar Jha <saagarjha28 at gmail.com <mailto:saagarjha28 at gmail.com>> wrote:
>> 
>> I have updated the proposal here <https://gist.github.com/saagarjha/f33fecd4576f40133b6469da942ef453>. Since this is a potentially a source breaking change, I’d like this to be considered for Swift 3; unless anyone has any issues with it, I’m going to push this to swift-evolution.
> 

I know you don’t really want to discuss it, but since I don’t quite get what you mean, I was wondering if you could clarify a bit more why this proposal is inappropriate.

> Some comments:
> - The syntax proposed would be *completely* unlike anything in Swift, and is semantically changing things unrelated to the type.

There is no new syntax proposed; it is simply a restriction on the current syntax of using IUOs in functions, which I feel encourages unsafe behavior. The “syntax change” is no more than changing something like this:

func triple(forceUnwrapping aNumber: Int!) -> Int? {
    guard aNumber != nil else {
        return nil
    }
    return aNumber * 3
}
to

func triple(withoutUnwrapping aNumber: Int?) -> Int? {
    guard let aNumber = aNumber else { // simply transform the check
        return nil
    }
    return aNumber * 3
}

There’s not much of a difference, except that at the it makes it easier to see that nil is properly handled at the call site.

> - This proposal doesn’t work, and overly punishes IUOs.

My goal is not to “punish” IUOs. I recognize that IUOs have valid uses, for example during initialization–and I want to leave this alone since this is the purpose of IUOs. My issue is with IUOs being “used as Optionals” in that they are allowed to have a nil value and checked for it (or not, with disastrous results). I’ve yet to see a function with an IUO parameter that couldn’t be rewritten to be clearer and more safe with a plain Optional parameter. Is there anything I’ve overlooked?

> 
> I recommend that we do not discuss this proposal, as it would not be a good use of community time.  Beyond the unworkability of this specific proposal, in my personal opinion, there is nothing wrong with the T! syntax.  Making it significantly more verbose would be a very *bad* thing for the intended use cases.

As before, this proposal is not an attack on IUOs and the T! syntax, it’s against their misuse as function parameters and return values. A significant increase in verbosity is obviously undesirable, but I don’t see how this proposal will cause an increase in length.

> 
> -Chris
> 
>> 
>> Saagar Jha
>> 
>> 
>> 
>>> On Jul 5, 2016, at 13:30, Saagar Jha <saagarjha28 at gmail.com <mailto:saagarjha28 at gmail.com>> wrote:
>>> 
>>> Gave me a chuckle, but yeah, basically.
>>> 
>>> On Tue, Jul 5, 2016 at 12:54 PM William Jon Shipley <wjs at delicious-monster.com <mailto:wjs at delicious-monster.com>> wrote:
>>> On Jun 30, 2016, at 9:22 AM, Saagar Jha via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>>>> When I see an IUO property, I consider it a sort of “contract”–it’s basically saying something like “I can’t set this to a valid value right now, but by the time you use it I promise that it’s non nil”
>>> 
>>> You might say that an IUO is sort of an IOU?
>>> 
>>> -W
>>> -- 
>>> -Saagar Jha
>> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160720/80612257/attachment.html>