Per the naming of the cancellation reasons; it seems to me that it boils down to the tension between the concept of "not cancelled and therefore has no reason" and the concept of "no reason given but still cancelled". Which that does lend a bit of credence to the idea of
That name does encapsulate the concept of no reason given but still cancelled. So I don't hate that as a solution, but it does leave the reason then optional and the nil case meaning not cancelled. So in practice, the very few folks who would need this would switch as:
switch Task.cancellationReason {
case . deadlineExpired:
break // a deadline happened
case .unspecified:
break // some other thing cancelled but not for a deadline reasoning
case .none:
// it wasn't cancelled
}
// and the cancellation error switch
switch cancellationError.reason {
case . deadlineExpired:
break // a deadline happened
case .unspecified:
break // some other thing cancelled but not for a deadline reasoning
}
@John_McCall you were the one who voiced some opposition to the naming of .taskCancelled, does .unspecified suffice as well as the .userRequested suggestion? I feel like it might actually be slightly better. (but tbh it is splitting hairs at this point)