(Comments inline) Saagar Jha
> On Jul 20, 2016, at 16:47, Saagar Jha <[email protected]> wrote: > > > > On Wed, Jul 20, 2016 at 12:52 PM Chris Lattner <[email protected] > <mailto:[email protected]>> wrote: > On Jul 19, 2016, at 3:46 PM, Saagar Jha <[email protected] > <mailto:[email protected]>> 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 <[email protected] >>> <mailto:[email protected]>> wrote: >>> >>> Gave me a chuckle, but yeah, basically. >>> >>> On Tue, Jul 5, 2016 at 12:54 PM William Jon Shipley >>> <[email protected] <mailto:[email protected]>> wrote: >>> On Jun 30, 2016, at 9:22 AM, Saagar Jha via swift-evolution >>> <[email protected] <mailto:[email protected]>> 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 >>
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
