> On Dec 26, 2016, at 09:38, thislooksfun via swift-evolution > <[email protected]> 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 [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
