John McCall +1 I agree. The placement should remain the same. On Tue, Jan 3, 2017 at 8:29 AM John McCall via swift-evolution < swift-evolution@swift.org> wrote:
> On Dec 29, 2016, at 12:33 AM, Dave Abrahams via swift-evolution < > swift-evolution@swift.org> wrote: > > > on Wed Dec 28 2016, Chris Lattner <clattner-AT-apple.com > <http://clattner-at-apple.com/>> wrote: > > On Dec 28, 2016, at 9:52 AM, Dave Abrahams <dabrah...@apple.com> wrote: > > it would be ambiguous to move the ‘throws’ keyword to the end of the > function type, because you'd get: > > > let x : (_ a : Int) -> (_ b: Float) -> Double throws throws > > > I see. > > We *could* say that the "throws" keyword comes after the return type > unless it's a function type, in which case it comes after the return > type's parameter list > > let x : (_ a : Int) -> (_ b: Float) throws -> Double throws > > I admit this is a horrible rule from a language designer's point of view > but there's a chance it could end up being better for users. > > > Indeed this is horrid for an ivory tower language designer, but the > pragmatic among them often have to make concessions to the real world. > That said, I think this would be worse for typical swift programmers > as well: it introduces multiple ways to do things, > > > Do you mean it introduces multiple ways to do the *same* thing? I > didn't think I was introducing any of those. If you think I was, you > probably misunderstood my suggestion (or I did!), FWIW. > > > Chris's point is that we can't stop allowing "throws" where it currently > is, and > therefore any proposal which allows it in a new place creates two ways of > spelling the same thing. > > Also, your proposal reinterprets the currently-valid syntax: > (_ a : Int) -> (_ b : Float) throws -> Double > Currently this means a non-throwing function that returns a throwing > function. > Your proposal flips it around. > > Also, I would find this extremely surprising as a user. A core aspect of > the > first function type is written *inside* the second? With all respect, > Dave, > that is just bizarre. :) > > I'm sorry if people dislike the placement of "throws", but that ship has > sailed, > and any attempt to "fix" it at this point is just going to cause problems > for > negligible benefit. > > As I see it, the current syntax has one mild deficiency, called out > previously > in this thread: a reader has to recognize that "throws -> X" does not mean > that the function throws an X, but instead that it either throws or > returns an X. > It's always nice when something is immediately obvious and doesn't have to > be explicitly learned, and I appreciate and mourn that my design may have > fallen short of that standard here. However, overall I still do think the > syntax > is much cleaner than the alternatives, especially as return types grow more > complicated, and that this small rule is not at all difficult to master. > > For what it's worth, this visual ambiguity is precisely why I would insist > that > any typed-throws addition be spelled "throws(X)" instead of "throws X". > > John. > > > > which work inconsistently and surprisingly in some cases. > > Here is a different way of looking at this: The predictable case is > the one we already have now (and we wouldn’t take it away). Is your > beef with the current syntax so great that you think it is worth > adding complexity to the language to privilege some special cases? > > > Not really, no. > > -- > -Dave > _______________________________________________ > swift-evolution mailing list > swift-evolution@swift.org > https://lists.swift.org/mailman/listinfo/swift-evolution > > > _______________________________________________ > swift-evolution mailing list > swift-evolution@swift.org > https://lists.swift.org/mailman/listinfo/swift-evolution >
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution