Typed throw functions

Evolution Discussion
, ,
10

Whenever I see things like this, showing the versioning troubles people are already having with errors, I’m glad we don’t have typed throws.

Specifically, things like this:

  • Using enumerations to represent Error s is inadvisable, as if new errors need to be introduced they cannot be added to existing enumerations. This leads to a proliferation of Error enumerations. "Fake" enumerations can be made using struct s and static let s, but these do not work with the nice Error pattern-match logic in catch blocks, requiring type casts.

At least they have the escape hatch of multiple enums! It’s not pretty, and the better approach is to use a struct, but people use enums anyway :man_shrugging:

Could you imagine if we had this, and every library had been striving to include the error types of throwing functions as part of their signature? The ecosystem would be much more fragile.

I would consider the pitch I just linked a prerequisite for even considering typed throws. Otherwise it’s too dangerous to be made so easy. In the mean time, those who really want it have Result.

Additionally, as part of typed throws, I would consider making any enum which conforms to Error resilient by default (with an ability to opt-out by marking it @frozen). Thrown errors will be gaining ABI significance, so it’s important developers think about this.

1 Like