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

[Tyler Cloutier]

> On Jan 9, 2017, at 1:10 AM, Tyler Cloutier <cloutiertyler at aol.com> wrote:
> 
>> 
>> On Dec 26, 2016, at 2:55 PM, Dave Abrahams via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>> 
>> 
>> on Mon Dec 26 2016, thislooksfun <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
>> 
>> I agree that reads much better.
> 
> func baz() -> (String | throws)
> func baz() -> (String | throws: BazError)
> let x: (_ a: Int) ->  (throws | (_ b: Float) -> (throws | Double))
> 
> Now where getting somewhere. Somewhere weird, to be sure… but somewhere.


Better yet, just add coproduct or union types, analogous to tuples, and it all seems to simplify.

let x: (_ a: Int) -> (Error | (_ b: Float) -> (Error | Double))
let x: (_ a: Int) -> (Error | Double)

No need to toss the try syntax either. It could be complementary.

let y = try! x(5)

let z = try? x(6)

let w = try x(8) catch { case(error: MyError) in

} catch { case(error: Error) in

}

switch x(7) {
case(let e: Error): ...
case(let x: Double): ...
}

if case(let x: Double) = x(9) {

}

Obviously I’m going off on a tangent and I suppose my Scala is showing with those case pattern matches. Certainly a lot of directions to go here. One very sad thing here is it makes a seemingly ordinary type (Error) have magical (catch, try) syntax. This not meant to be taken too seriously, since I’m just avoiding going to sleep.


> 
> 
>> 
>>> // 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
>>> 
>> 
>> -- 
>> -Dave
>> 
>> _______________________________________________
>> 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/20170109/ff909a35/attachment.html>