> 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
