I like to imagine "throws -> returnType" like a special tuple let t = (e: NSError?, r: returnType)
Where "try" is a special function that accepts a tuple argument; a success closure; and one or more error blocks func try( _ t: (e: NSError?, r: returnType) , do: ()->() , catch: ((Error)->())... ) So you could think of it as modifying the return type. On Mon, Dec 26, 2016 at 8:19 PM Daniel Leping via swift-evolution < swift-evolution@swift.org> wrote: > IMO, considering "throws" is a modifier of function/method and determines > how the function can be called (another good example is mutating) the > logical approach would be to make things consistent and move everything > either to the beginning or to the end of declaration. > > As long as "throws" is the only modifier at the end it's very logical to > move it to the beginning and rename to "throwing". It feels like "throws" > at the end is rather a legacy, probably from other languages and was a > _default_ way of thinking at the time of initial implementation. > > I personally can live with both, though for the sake of consistency it > should be moved to the beginning. > > On Tue, 27 Dec 2016 at 6:00 thislooksfun via swift-evolution < > swift-evolution@swift.org> wrote: > > As far as I know, `throws` only affects whether or not the code must be > marked with a `try` statement, the actual return type/value is unchanged > (since it would be unreached if an error was thrown). > > > > -thislooksfun (tlf) > > > > > > > > > > On Dec 26, 2016, at 1:18 PM, David Sweeris <daveswee...@mac.com> wrote: > > > On Dec 26, 2016, at 09:38, thislooksfun via swift-evolution < > swift-evolution@swift.org> wrote: > > Hello Swifters, > > I've been writing a lot more Swift code recently, and I have found that > the default placement of the 'throws' declaration is often confusing, > especially to those of us switching from languages where the type of errors > thrown is explicitly defined (like Java) > > For example, > > // This is pretty clear, this can throw an error > > func foo() throws > > { ... } > > > > // Also pretty clear, this returns a String > > func bar() -> String > > { ... } > > > > // Confusing. Does this throw a String? Does it return a String? Does it do > both? > > // I personally keep reading this as 'this can throw a String' > > func baz() throws -> String > > > > // Equivalent code in Java (not a model, just for clarification of why the > above is confusing) > > String baz() throws StringFormatException > > I therefore suggest either tweaking the syntax around, or moving, the > `throws` keyword to avoid this confusion. > > Some ideas I've had: > > // Add a comma to separate them > > func baz() throws, -> String > > > > // Move `throws` to the end > > func baz() -> String throws > > > > // Change it to a prefix modifier (like `mutating`) > > throwing func baz() -> String > > I'm still not sold on any of the above syntaxes, but I would love to hear > your feedback. > > This would affect existing code, but it would be a fairly small change > that would result in very large readability improvements, especially for > newcomers, and *especially* for those coming for a language such as Java. > > -thislooksfun (tlf) > > > Does `throws` affect the actual return type? That is, is the size of the > returned data different between "func foo() -> Int8" and "func foo() throws > -> Int8"? If so, the "throws" is quite literally part of the return type > and the current syntax reflects that. If not, I *think* I'd probably be > in favor of that last "prefix modifier" suggestion with either "throwing" > or "@throwing" (depending on the exact semantics of the "@" part — I'm a > bit unclear on that detail)... probably... maybe... I'll have to think > about it some more. > > - Dave Sweeris > > > _______________________________________________ > > 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