"throws" makes more sense closer to the end of the function signature because it's an outcome like the return type. Swift's function syntax is fairly consistent in this regard: <modifiers> func <name>(<inputs>) <outcomes>.
Personally, I think the keyword is fine where it is and this is the kind of change where there would have to be *significant* advantages to changing it. I think it would be hard to make the case that a change at this point would warrant breaking existing code. On Mon, Dec 26, 2016 at 10:59 AM Lucas Neiva via swift-evolution < [email protected]> wrote: > I like "throwing" as a prefix. It's reads well and fits very nicely with > "mutating". > > Remembering where to put the keyword for is also easier if it's at the > beginning, where it fits grammatically as "throwing func". > > On 26 Dec 2016, at 19:53, Micah Hainline via swift-evolution < > [email protected]> wrote: > > I'd prefer the placement at the very end, I do think it would improve > readability, especially when taking closures as parameters and returning > closures. However, I don't think the value would be worth the cost of > breaking existing code. At the least if this were to go forward I would > think we'd want both styles to work even if one was preferred or the other > was deprecated. > > > > On Dec 26, 2016, at 12:41 PM, Derrick Ho via swift-evolution < > [email protected]> wrote: > > I personally do not see anything wrong with its current placement. > > It may be there because it was based on an existing cocoa pattern from > objective-c > > - (NSString *)bazWithError:(NSError **)error { ... } > > Because objective c could only return one thing, using pointer-to-pointer > was needed to deliver more than one. > > When swift came along it became this... > > func baz(error: NSErrorPointer) -> String > > The style felt old-fashioned and was replaced with throw. > > func baz() throws -> String > > > The evolution is consistent. The pattern is familiar. I think we should > keep the placement of throw as it is. > > On Mon, Dec 26, 2016 at 9:38 AM 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) > > > > > > > > _______________________________________________ > > > 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 >
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
