[Pitch N+1] Typed Throws

[dmt (Dima Galimzianov)]

@Slava_Pestov

This one relies on a generalization of the rules that is (I believe) straightforward but hasn't been discussed so far. We want to say that WrappedError<Never> behaves like Never for typed throws purposes, so a function throwing WrappedError<Never> is not considered as throwing. Otherwise, this example does not mimic rethrows at all.

We could achieve that if we allowed any uninhabited type to behave like Never in error position. In this case, WrappedError<Never> is uninhabited because it has a stored property of type E.

Yes, exactly. I wrote about this in the previous thread as a reply to @Joe_Groff 's proposal of Uninhabited protocol and its inference.

Status check: Typed throws

Hm. struct S<T> { init(_: T) {} } The struct should be inferred to be uninhabited when T: Uninhabited, but its layout tells us nothing about it. It's impossibility to construct a value of this type makes it uninhabited. But inits aren't always visible. So automatic conformance to Uninhabited could be challenging. It's certainly possible for enums and types with stored properties of uninhabited types. But in general case it seems a bit too much for an automated conformance. Another exampl…