[swift-evolution] Move placement of 'throws' statement

[Derrick Ho]

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 <
swift-evolution at 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)







_______________________________________________


swift-evolution mailing list


swift-evolution at swift.org


https://lists.swift.org/mailman/listinfo/swift-evolution
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20161226/1d779856/attachment.html>