[Typed throws] Handle function conversions involving different thrown errors #68995
Conversation
… errors
Teach the constraint solver about the subtyping rule that permits
converting one function type to another when the effective thrown error
type of one is a subtype of the effective thrown error type of the
other, using `any Error` for untyped throws and `Never` for
non-throwing.
With minor other fixes, this allows us to use typed throws for generic
functions that carry a typed error from their arguments through to
themselves, which is in effect a typed `rethrows`:
```swift
func mapArray<T, U, E: Error>(_ array: [T], body: (T) throws(E) -> U)
throws(E) -> [U] {
var resultArray: [U] = .init()
for value in array {
resultArray.append(try body(value))
}
return resultArray
}
```
DougGregor
requested review from
hborla,
slavapestov,
AnthonyLatsis and
xedin
as code owners
|
@swift-ci please smoke test |
This won't happen in "normal" Swift code, but can occur with tests that use `-parse-stdlib`.
|
@swift-ci please smoke test |
lib/Sema/CSSimplify.cpp
Outdated
| @@ -14999,6 +15105,7 @@ ConstraintSystem::SolutionKind ConstraintSystem::simplifyFixConstraint( | |||
| case FixKind::AllowAssociatedValueMismatch: | |||
| case FixKind::GenericArgumentsMismatch: | |||
| case FixKind::AllowConcreteTypeSpecialization: | |||
| case FixKind::IgnoreThrownErrorMismatch: | |||
There was a problem hiding this comment.
I wonder how impactful this fix is vs. i.e. @escaping mismatch should it be more like a conversion mismatch which is has impact of 2?
There was a problem hiding this comment.
I don't have a good sense of what the right impact score should be. I'll go with your suggestion of 2.
There was a problem hiding this comment.
If one overload choice has a mismatch on argument or result type and another on throws should that be ambiguous?
There was a problem hiding this comment.
No, I would not think it should be ambiguous. Within a single module, we don't allow overloading on throws alone, but of course this overloading can happen across module boundaries.
There was a problem hiding this comment.
What I am trying to ask is what overload is going to be a better suggestion in such case or whether both overloads should be mentioned, that’s where the impact matters.
|
@swift-ci please smoke test |
Teach the constraint solver about the subtyping rule that permits converting one function type to another when the effective thrown error type of one is a subtype of the effective thrown error type of the other, using
any Errorfor untyped throws andNeverfor non-throwing.With minor other fixes, this allows us to use typed throws for generic functions that carry a typed error from their arguments through to themselves, which is in effect a typed
rethrows: