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

[Tony Allevato]

One thing to keep in mind is that, if I recall correctly, some members of
the core team have expressed a desire to enhance `throws` by letting users
list the specific error types that a function can throw. If that is
something that might happen in the future, moving the `throws/throwing` to
the front would add a significant amount of noise before the function name.


On Mon, Dec 26, 2016 at 10:29 PM Karl via swift-evolution <
swift-evolution at swift.org> wrote:

> I agree that this could do with revision. It looks particularly ugly when
> you’re dealing with throwing closures.
>
> Recently I had a signature like:
>
> public func scan(length: File.ByteOffset.Stride?,
>                      by frameSize: File.ByteOffset.Stride,
>                      with handler:
> (_ range: Range<File.ByteOffset>, _ data: UnsafeRawBufferPointer) throws -> Bool) throws -> File.ByteOffset.Stride
>
> It can get difficult to parse the signature towards the end. Marking the
> handler and function as throwing closer to the beginning would make it more
> readable IMO. One thing it allows me to do more easily is to remove the
> spaces around the arrow for the closure parameter (just a little thing
> which I find helps me read the trailing closure/return type more quickly).
>
> public throwing func scan(length: File.ByteOffset.Stride?,
>                                          by
> frameSize: File.ByteOffset.Stride,
>                                          with handler: throwing
> (_ range: Range<File.ByteOffset>, _ data: UnsafeRawBufferPointer)->Bool)
> -> File.ByteOffset.Stride
>
> - Karl
>
> On 26 Dec 2016, at 18:38, 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
>
> _______________________________________________
> 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/20161227/51a9b74e/attachment.html>