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 <clatt...@apple.com> wrote: > >> >> On Jul 20, 2016, at 12:52 PM, Chris Lattner <clatt...@apple.com >> <mailto:clatt...@apple.com>> wrote: >> >> On Jul 19, 2016, at 3:46 PM, Saagar Jha <saagarjh...@gmail.com >> <mailto:saagarjh...@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
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
