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

[Saagar Jha]

Sorry for the last email…I didn’t see your response.

I realize that disallowing IUOs in parameters (but not as properties) is inconsistent, but IUOs for properties make sense: they must be set during initialization, but sometimes this isn’t possible. IUOs make it possible to use the property just as any other non-Optional one, provided the property is set before it is used (see the proposal). This kind of guarantee doesn’t work for function parameters and return values. 

As for IUOs for non-audited methods; why can’t they just all use Optional parameters? It should have the same behavior as before, since you can pass in both an Optional as well as a non-Optional even today.

Saagar Jha



> On Jul 20, 2016, at 17:13, Chris Lattner <clattner at apple.com> wrote:
> 
>> 
>> On 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.
>> 
>> Some comments:
>> - The syntax proposed would be *completely* unlike anything in Swift, and is semantically changing things unrelated to the type.
>> - This proposal doesn’t work, and overly punishes IUOs.
>> 
>> 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.
> 
> Hi Saagar,
> 
> I’m sorry for the response above, I apparently misunderstood your early example to read it as putting the force unwrapping concept into the “forceUnwrapping” parameter label.
> 
> I now see that your idea is to remove force unwrapping entirely for parameters.  I am very concerned about this and think it would not be accepted into Swift.  It makes the language less consistent (why can you do it on a property, but not a parameter) and eliminates important use cases for T!: overriding an non-nullability audited method.
> 
> -Chris

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