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

[Karl]

Maybe we can let the compiler use documentation comments for type-checking. Currently you can do:

/// does something
///
/// - returns: Something cool
///
/// - throws:
///    - `MyError.Something` if a certain thing happens
///    - `POSIXError` if something goes horribly wrong
///
func doSomething() throws -> Int

I would prefer if we found some way to integrate that stuff in to the compiler. I mean, you would probably want to document why the errors get thrown anyway, and it’s better than clobbering up the function signature.

Maybe it seems weird to have the compiler look inside comments (especially if the set of thrown errors becomes a resilience-breaking part of the function), but why not? Swift’s documentation comments are just another source of structured data, and the compiler already understands them at a superficial level.

Just saying, there are options.

> On 27 Dec 2016, at 07:55, Tony Allevato <tony.allevato at gmail.com> wrote:
> 
> 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 <mailto: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 <mailto: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 <mailto:swift-evolution at swift.org>
>> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
> https://lists.swift.org/mailman/listinfo/swift-evolution <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/7a34737e/attachment.html>