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

[Derrick Ho]

I like to imagine "throws -> returnType" like a special tuple

let t = (e: NSError?, r: returnType)

Where "try" is a special function that accepts a tuple argument; a success
closure; and one or more error blocks

func try(
_ t: (e: NSError?, r: returnType)
, do: ()->()
, catch: ((Error)->())...
)

So you could think of it as modifying the return type.
On Mon, Dec 26, 2016 at 8:19 PM Daniel Leping via swift-evolution <
swift-evolution at swift.org> wrote:

> IMO, considering "throws" is a modifier of function/method and determines
> how the function can be called (another good example is mutating) the
> logical approach would be to make things consistent and move everything
> either to the beginning or to the end of declaration.
>
> As long as "throws" is the only modifier at the end it's very logical to
> move it to the beginning and rename to "throwing". It feels like "throws"
> at the end is rather a legacy, probably from other languages and was a
> _default_ way of thinking at the time of initial implementation.
>
> I personally can live with both, though for the sake of consistency it
> should be moved to the beginning.
>
> On Tue, 27 Dec 2016 at 6:00 thislooksfun via swift-evolution <
> swift-evolution at swift.org> wrote:
>
> As far as I know, `throws` only affects whether or not the code must be
> marked with a `try` statement, the actual return type/value is unchanged
> (since it would be unreached if an error was thrown).
>
>
>
> -thislooksfun (tlf)
>
>
>
>
>
>
>
>
>
> On Dec 26, 2016, at 1:18 PM, David Sweeris <davesweeris at mac.com> wrote:
>
>
> On Dec 26, 2016, at 09: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)
>
>
> Does `throws` affect the actual return type? That is, is the size of the
> returned data different between "func foo() -> Int8" and "func foo() throws
> -> Int8"? If so, the "throws" is quite literally part of the return type
> and the current syntax reflects that. If not, I *think* I'd probably be
> in favor of that last "prefix modifier" suggestion with either "throwing"
> or "@throwing" (depending on the exact semantics of the "@" part — I'm a
> bit unclear on that detail)... probably... maybe... I'll have to think
> about it some more.
>
> - Dave Sweeris
>
>
> _______________________________________________
>
> 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/eaf376f1/attachment.html>