> On 3 Jan 2017, at 16:29, John McCall via swift-evolution > <swift-evolution@swift.org> wrote: > > > > 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.
I’m going to stand up for the way it is now. I do not think the design falls short or is deficient. Bearing in mind that “->” actually means “returns”, I honestly can’t see why anybody would think func foo() throws -> Int could possibly be a function that throws an Int, especially if they have any knowledge of how the throw mechanism works in Swift (or any other language, for that matter). If it had been decided to put throws at the end, we’d probably be having an argument now that func foo() -> Int throws appears to return an Int that throws, an argument with much more validity, as pointed out upthread, because func foo() -> () -> Int throws really is ambiguous. > > 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