> On 4 Jan 2017, at 20:39, thislooksfun <[email protected]> wrote: > > I still personally prefer the `throwing` prefix, but the way it currently is > also works just fine, I'll just have to adjust.
Yes, if error throwing had come up on Swift Evolution before it was implemented, I would have been in that camp too, mainly because of my Objective-C and Java background - it would have seemed “logical" to me to put the “denotes can throw” keyword at the opposite end of the declaration to the return type. However, I am now used to the way it is and I think it works fine. > > -thislooksfun (tlf) > >> On Jan 4, 2017, at 6:10 AM, Jeremy Pereira via swift-evolution >> <[email protected]> wrote: >> >>> >>> On 3 Jan 2017, at 16:29, John McCall via swift-evolution >>> <[email protected]> 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 >>>> [email protected] >>>> https://lists.swift.org/mailman/listinfo/swift-evolution >>> >>> _______________________________________________ >>> swift-evolution mailing list >>> [email protected] >>> https://lists.swift.org/mailman/listinfo/swift-evolution >> >> _______________________________________________ >> swift-evolution mailing list >> [email protected] >> https://lists.swift.org/mailman/listinfo/swift-evolution > _______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
