xwu
June 26, 2021, 11:30pm
126
This was not overlooked during review; apparently, it is the intended design, and the possibility of creating a continuation with a concrete Error type is merely future-proofing "in case" we get typed errors.
In the same vein, it seems that the design as-is doesn't really make use of a parameterized error type. It seems like either with*ThrowingContinuation should use a parameterized error type too, or the *Continuation types should not.
This is the issue with including error parameters in these APIs in general; they're more for future proofing in case we add typed errors in the future, even if today you can only really use them with Never and Error . Since we've decided to also include error type parameters in other parts of the API, like Task.Handle and Task.Group , it seems worth it to be consistent here.