[Accepted] SE-0413: Typed throws

taylorswift · 2023-12-26T00:34:01.596Z

tapoton:

This explanation is not very detailed, it tells about intuitiveness and even gives an example of angle brackets usage in macros.

one way to think about it is that angle brackets declare type parameters, but the types that go in throws(...) are just plain old types.

MPLewis · 2023-12-26T01:05:38.765Z

I personally like the symmetry here with the types inside the parentheses for the parameters list too.

DevAndArtist · 2023-12-26T13:41:02.557Z

I was almost about to ask something similar but I remembered that the angle brackets usually signal a generic type list. In case of typed throws this would not be true unless the generic error type is declared in the leading angle brackets. Therefore they do not fit, which also implies why normal parenthesis suit better here.

tapoton · 2023-12-26T13:50:42.132Z

I was looking at throws keyword more like at an attribute that is generic itself. Just like you could specify function argument type or return value type:

func foo(arg: Bar<Int>) -> Baz<String>
func foo<T>(arg: Bar<T>) -> Baz<Qux<T>>

that would naturally look the same with throws not as a declaration, but as a specification of generic type:

func foo<T>(arg: Bar<T>) throws<MyError<T>>

At the same time using parentheses looks more like a second argument list, or another function declaration that an author forgot to move to a new line:

func foo<T>(arg: Bar<T>) throws(MyError<T>)

DevAndArtist · 2023-12-26T13:54:48.188Z

I understand your point, yet I think the actual error type is not generic and therefore angle brackets seem out of place, to me at least.

sspringer · 2023-12-26T14:00:58.873Z

tapoton:

At the same time using parentheses looks more like a second argument list…

Funny, now that the syntax is fixed, people will get accustomed to it and have their own “pictures” in their heads, for me the round parentheses look like an additional remark (the same way they are used in normal text): “Look, it can throw something, and by the way, this is what it then throws.”

spadafiva · 2023-12-26T14:03:29.400Z

That’s why I preferred the angle brackets as well. You can’t usually take the name of a type directly as a parameter. I would have expected to see throws(SomeError.self) with the regular parenthesis.

DevAndArtist · 2023-12-26T14:16:51.495Z

In that case it would mean that generic type is passed as a value. However a throwing function is simply a function with two different return paths, the regular return type and the error type. Therefore it’s part of the signature and isn't a parameter, hence no need for .self or .Type.

sspringer · 2023-12-27T06:06:20.620Z

… and next (hopefully) are sum types

BrentM · 2023-12-28T15:33:12.942Z

Wouldn’t throws Type (without parentheses) be more in line with the syntax we have today for other key words that appear at the end of a function?

Eg.

fun foo() where Self == Equatable

On a side note, will this work with generics?

For example:

struct MyStruct<MyError: Error> {
    fun foo() throws (MyError) {
    }
}

ksluder · 2023-12-28T15:40:04.574Z

The syntax was heavily debated over the very long course of the review process. I doubt the language workgroup is going to reopen the discussion at this point.

scanon · 2023-12-28T15:56:06.268Z

BrentM:

Wouldn’t throws Type (without parentheses) be more in line with the syntax we have today for other key words that appear at the end of a function?

This is directly addressed in both the proposal text and the acceptance (this thread, "Parentheses").

BrentM:

On a side note, will this work with generics?

For example:
struct MyStruct<MyError: Error> {
    fun foo() throws (MyError) {
    }
}

Try it yourself: Compiler Explorer (Yes, it works, but you'll have to constrain MyError to something that refines Error in order to actually be able to construct one to throw, because Error requires neither and initializer nor static members. Here's a worked example.)

bbrk24 · 2023-12-28T16:12:56.718Z

scanon:

you'll have to constrain MyError to something that refines Error in order to actually be able to construct one to throw

Not necessarily:

struct ErrorHolder<T: Error> {
  private var error: T?

  mutating func gimmeAnError(_ error: T) {
    self.error = error
  }

  func checkError() throws(T) {
    if let error { throw error }
  }
}

cadnza · 2024-04-22T13:36:06.038Z

New member here; very interested in this proposal. Has the discussion continued elsewhere since the end of last year?

xwu · 2024-04-22T13:59:36.644Z

Hi @cadnza, as you can see from the title of this thread, we have announced that this proposal is accepted. You can try it out for yourself (see swift.org for download instructions)!

cadnza · 2024-04-22T14:05:09.608Z

Ah, got it. Thank you!

James_Dempsey · 2024-07-15T16:58:11.737Z

Is this proposal implemented in Swift 6.0?

It is still appearing as "Accepted" on the evolution dashboard because the status of the proposal has not been updated.

@scanon

xwu · 2024-07-15T18:07:18.337Z

Not fully—see this thread: Where is FullTypedThrows?

James_Dempsey · 2024-07-15T18:13:19.093Z

@xwu Thank you!

Douglas_Gregor · 2024-07-15T18:14:25.562Z

xwu:

Not fully—see this thread: Where is FullTypedThrows?

Yeah, we'll need to figure out how to deal with this. The bulk of the feature is in 6.0, but the implementation does not support the type inference rules (FullTypedThrows) and the standard library is missing some adoption of typed throws.

Doug