Status check: Typed throws

[Joe_Groff]

@ksluder

Yikes, okay. In that case, I hope this functionality would never be made available for resilient libraries! I strongly believe such ABI boundaries should always use untyped throws.

I hope this also forces us to bring non-exhaustive enums to non-resilient Swift libraries. That would be the other way for libraries that need to work in runtime-limited environments to provide source-stable yet expandable error types.

[DevAndArtist (Adrian Meister)]

Ah okay, I guess I misunderstood it then. I had the feeling it meant that () -> Void meaning () throws(Never) -> Void is an "unfortunate" change. I personally like that direction.

But I understand now that the way "non-throwingness" could be determined, shouldn't be limited to just Never.

[anandabits (Matthew Johnson)]

@John_McCall

Can you explain why this is important? You have a lot of generic error types that become uninhabited for specific applications?

I don’t have a concrete example to provide off the top of my head, but I am confident people will eventually bump into problems without it. If I find a good concrete example I’ll add it to the thread.

@DevAndArtist

What's the difference between a non-throwing entity and one that throws Never? To me the latter opens up a great generalization where you can easily write generic algorithms including the error types.

I am describing a generalization that goes further than non-throwing being equivalent to throws Never. For example, throws MarkerType would also be non-throwing where `MarkerType is declared as:

enum MarkerType: MarkerProtocol { }

Obviously this is a silly example, but in I believe there are cases where it would be important in terms of usability of generic libraries. The most important point is that absence of this design element could impact users of a library (forcing them to “handle” errors that can never be thrown).

[taylorswift]

@John_McCall

Can you explain why this is important? You have a lot of generic error types that become uninhabited for specific applications?

i often find it valuable to define my own uninhabited types, because Never is a shared namespace, and over the past year or so i’ve been gradually moving away from adding conformances and extension members to Never in favor of adding things to custom empty enums.

i don’t do it too often for error types, i usually do it for “type constants” (e.g. Limit.One, Days.Monday, etc.) in some overly-clever API, but i can see how it could be valuable for error types for similar reasons.

[Joe_Groff]

I think there would be formal issues in the type system with treating throws(Uninhabited) as canonically equivalent to nonthrowing in all cases, since that would create a weird (to my non-type-system-expert eyes) type checking problem unifying (A) -> R with (A) throws(E) -> R; the non-concrete type (A) -> R suddenly becomes generically equivalent to forall E: Uninhabited & Error . (A) throws(E) -> R. However, maybe there could be an implicit conversion from throws(Uninhabited) to nonthrowing when we can see statically that the type is uninhabited, though that also has the problem of introducing a cyclic subtyping relationship.

If nothing else, it seems like we could at least let you call a function with an uninhabited error type without a try and outside of a throws or do { } catch {} context.

[dmt (Dima Galimzianov)]

Is there a case when this equivalence don't hold? Seems like all instances of those types fundamentally equivalent (due to the fact that such instances do not exist)?

let a: Never1
let b: Never2

a ≡ b
(which means you can use them interchangebly)

But
Never1.self ≢ Never2.self

[Joe_Groff]

All uninhabited types are isomorphic, but there may be interesting distinctions to draw using different types to represent different reasons for being uninhabited. Since they have no actual values, and any code that claims to have a value is by definition unreachable, it is trivial to "convert" one to any other type:

func convert<T>(from: Never) -> T { switch from {} }

but the only reason to do that is to fill in some type mismatch between components.

[Douglas_Gregor]

@dhoepfl

For me, it does not feel like the “happy middle” but like “gave up before it was done”.

If there is only one type allowed, I will end up writing boiler plate code to throw an enum for what could have been a list of types in the first place.

I think of it in the same dichotomy as describe by @ellie20, where either you have a domain-specific error (that you deal with) or you have general errors, and that any attempt to enumerate "more than one" error is poor API design.

It's clear that a proposal will need to provide extensive arguments for this view point. It's going to come up a lot:

@Sajjon

But what would be amazing, would be some kind of Swift compiler magic, which would allow me to just do:

public func fetchUser(...) async throws(MyError) -> User {
	let data = try await makeNetworkRequest(path: "user/..")
	return try decode(data: data, as: User.self)
}

fetchUser is an API that depends on several different subsystems, which are likely to change over time, and decoding of fairly arbitrary data. This is a prime use case for untyped throws, and I think it's wrong to seek syntactic sugar for it.

@anandabits

Both the proposal draft and the post from @John_McCall post seem to assume all non-throwing functions have error type of Never. This would be unfortunate. All functions with uninhabited error types should be considered non-throwing.

This implies a whole lot more for runtime type checking, because you have to be able to answer at runtime whether a particular type is uninhabited. That's not something we compute now at runtime, and it's not a trivial thing to compute for a generic enum because you have to look at all of the types of the associated values. Why? Here's a super-contrived example:

func f<E: Error>(_ value: Any, errorType: E.Type) { 
  typealias Fn = () throws(E) -> Void
  if let value as? Fn {
    print("Yes, it's a function that throws a \(E)")
  }
}

enum GE<T: Error>: Error {
  case one
  case two(T)
}

func g() { }

f(g, errorType: GE<Never>.self)

This would have to determine (at runtime, if we're not specializing f) that GE<Never> is an uninhabited type in order for Fn to collapse down to a non-throwing () -> Void and match the type of g. Maybe we can do that, but let's be clear that generalizing from Never to "all uninhabited types" is actually a lot of complexity.

@anandabits

The fundamental semantic of rethrows is that a function can only throw when an argument actually throws. In the presence of typed errors, it should be possible to catch and transform errors before rethrowing. This implies it should be possible to write rethrows TransformedError regardless of the error types thrown by arguments. In such a function, the body would catch the errors thrown by its arguments and convert them to TransformedError.

I had not thought of this, and had reflexively assumed we would ban rethrows(SomeError), but you have a good point!

@anandabits

The proposal mentions that type inference for general catch clauses was omitted due to requiring breaking changes. Hopefully this could be included in Swift 6.

Perhaps. I'd like us to consider inferring thrown types of closures as well, which is a more significant breaking change than the one for general catch clauses.

@anandabits

It would be great if error types could be opaque just like return types.

I hadn't thought of this, either. I can certainly see how it fits in the model, but I'm having a hard time coming up with a use case for it.

@olbo

I am not a compiler engineer or language engineer, but would it be possible for the compiler to make the error types implicit?

Implementation concerns aside, I do not think we should go down this route. Swift doesn't allow inference of result types for philosophical reasons: the important aspects of a function's interface are explicitly specified in its declaration, so you never need to inspect the body to understand how to interact with it. That same logic holds for typed throws as well.

@olbo

I imagine some developers may want to spell it out in the function signature, but some may prefer the ability to adapt to new error types without updating all signatures in their call stack.

The former can use typed throws, the latter should continue to use untyped throws.

@ksluder

Do you have a link handy to any discussions about why precise error handling is useful in Embedded Swift? I vaguely recall seeing one.

Untyped throws relies on the existential type any Error, and existential types---which are heavy on type metadata and heap allocation---are not part of the Embedded Swift subset as defined in the prospective vision.

Doug

[Joe_Groff]

@Douglas_Gregor

@olbo

I am not a compiler engineer or language engineer, but would it be possible for the compiler to make the error types implicit?

Implementation concerns aside, I do not think we should go down this route. Swift doesn't allow inference of result types for philosophical reasons: the important aspects of a function's interface are explicitly specified in its declaration, so you never need to inspect the body to understand how to interact with it. That same logic holds for typed throws as well.

I agree that we don't want to infer error types at the type system level and implicitly propagate that information across functions. It would however be a useful optimization that should be straightforward to implement once we have the pieces in place, to specialize a function that only throws one type of thing to use the ABI for throwing only that thing in the optimizer.

[Douglas_Gregor]

@Joe_Groff

I agree that we don't want to infer error types at the type system level and implicitly propagate that information across functions. It would however be a useful optimization that should be straightforward to implement once we have the pieces in place, to specialize a function that only throws one type of thing to use the ABI for throwing only that thing in the optimizer.

Oh, the optimization is absolutely fair game, and this is a great candidate for function signature optimizations like the one you describe. But I don't think it belongs in the language model.

Doug

[olbo (Oliver Atkinson)]

The spelling could be different, for example:

fun throwsA() throws _ {
  throw A()
}

[anandabits (Matthew Johnson)]

@Joe_Groff

If nothing else, it seems like we could at least let you call a function with an uninhabited error type without a try and outside of a throws or do { } catch {} context.

This is the most important part, so happy to hear that is feasible.

@Douglas_Gregor

@anandabits

It would be great if error types could be opaque just like return types.

I hadn't thought of this, either. I can certainly see how it fits in the model, but I'm having a hard time coming up with a use case for it.

I don’t have one handy off the top of my head, but it seems like something that could well come up in a library design sooner or later.

[filip-sakel]

IMO Decorated<T> should have some annotation to help the compiler understand that when T is uninhabited the type itself is uninhabited, e.g.

@conditionallyUninhabited(checkedProperties: "error")
struct Decorated<T: Error> {
  var error: T
  var decoration: Decoration
}

[dmt (Dima Galimzianov)]

@Douglas_Gregor

@anandabits

The fundamental semantic of rethrows is that a function can only throw when an argument actually throws. In the presence of typed errors, it should be possible to catch and transform errors before rethrowing. This implies it should be possible to write rethrows TransformedError regardless of the error types thrown by arguments. In such a function, the body would catch the errors thrown by its arguments and convert them to TransformedError.

I had not thought of this, and had reflexively assumed we would ban rethrows(SomeError), but you have a good point!

rethrows could be expressed as

func map<E: Error, R>(_ f: (T) throws(E) -> R) throws(MappedError<E>) -> MappedResult<R>

[dlbuckley (Dale Buckley)]

I just want to chime in and say that this feature concerns me and I don't think some people realise the implications of what they are asking for. Having a heavily layered codebase where you can anonymously bubble up errors deep within the system for a higher level to deal with where appropriate is one of the great strengths of swift. If we move away from that it makes larger codebases much more difficult to maintain and less flexible.

I'm all for using types, it's great for correctness and I couldn't go back to not using them. But errors are inherently telling you something incorrect has happened and should be an escape hatch to quickly get back to a place which can handle them. We shouldn't need to be layering error type handling at every single layer.

If this continued to get pushed through then I just hope it's optional as I think mandatory error types will make the language much more clunky to use.

[Joe_Groff]

@filip-sakel

IMO Decorated<T> should have some annotation to help the compiler understand that when T is uninhabited the type itself is uninhabited, e.g.

@conditionallyUninhabited(checkedProperties: "error")
struct Decorated<T: Error> {
  var error: T
  var decoration: Decoration
}

We're planning to introduce some additional type layout properties as generic constraints, such as BitwiseCopyable for types that have no reference counting or deinit logic, and it seems like Uninhabited would be another reasonable candidate for one of those. When we have visibility into a type's layout, then we should be free to also look at the type layout to determine its habitability.

[Philippe_Hausler]

With typed throws we could eliminate some holes in Result

extension Result {
  @inlinable
  public func get() throws(Failure) -> Success {
    switch self {
    case let .success(success):
      return success
    case let .failure(failure):
      throw failure
    }
  }
}

That way a Result<String, Never> would not throw on the get(). (obviously this would be a breaking change and perhaps should be spelled as a new thing... perhaps a property value to mimic Task)

[Douglas_Gregor]

@dlbuckley

I'm all for using types, it's great for correctness and I couldn't go back to not using them. But errors are inherently telling you something incorrect has happened and should be an escape hatch to quickly get back to a place which can handle them. We shouldn't need to be layering error type handling at every single layer.

If this continued to get pushed through then I just hope it's optional as I think mandatory error types will make the language much more clunky to use.

It will absolutely remain optional, and I think your concerns are well-founded. This is why I'm being so stubborn about "there shall only be one thrown error type", with no affordances for specifying multiple error types or providing a union, because if you aren't in a domain where there is exactly one, you should be using the existing untyped throws. I think a lot of the desire to make typed throws featureful is coming from the assumption that most throwing functions should have typed throws, and I think the exact opposite is true: typed throws is the right tool for a narrow set of places where there's only one way in which things can fail, and untyped throws is the right default everywhere else.

Doug

[bbrk24]

@Douglas_Gregor

This would have to determine (at runtime, if we're not specializing f) that GE<Never> is an uninhabited type in order for Fn to collapse down to a non-throwing () -> Void and match the type of g.

Can’t you cast from () -> Void to () throws(Whatever) -> Void regardless?

[dlbuckley (Dale Buckley)]

@Douglas_Gregor

It will absolutely remain optional, and I think your concerns are well-founded. This is why I'm being so stubborn about "there shall only be one thrown error type", with no affordances for specifying multiple error types or providing a union, because if you aren't in a domain where there is exactly one, you should be using the existing untyped throws.

This has put my mind at rest somewhat, thank you! I still fear that if this gets implemented it will be abused, but thats down to the community to learn that lesson the hard way I imagine.