In our project we enabled the swift compiler diagnostics -Xfrontend -debug-time-expression-type-checking and we found there were a lot of time spent type-checking code that uses combineLatest and/or with(latestFrom:).
After digging deep in the issue we fount the root cause is coming from having these overloaded functions with generics from the library itself
Is this a know issue? and do you have a solution for this?
Example that triggers the warning when limit is 100ms. It shows us 170ms is spent on type-checking this expression
To give a better look, here is a snippet for the 3 overloaded functions extracted from SignalProtocol + Combining. The way they are written, they checking on error types for Element & O.
protocol SignalProtocol {
associatedType Element
public func combineLatest<O: SignalProtocol>(with other: O) -> Signal<(Element, O.Element), Error> where O.Error == Error
public func combineLatest<O: SignalProtocol>(with other: O) -> Signal<(Element, O.Element), Error> where O.Error == Never
}
extension SignalProtocol where Error == Never {
public func combineLatest<O: SignalProtocol>(with other: O) -> Signal<(Element, O.Element), O.Error>
}
In our project we enabled the swift compiler diagnostics
-Xfrontend -debug-time-expression-type-checking
and we found there were a lot of time spent type-checking code that usescombineLatest
and/orwith(latestFrom:)
.After digging deep in the issue we fount the root cause is coming from having these overloaded functions with generics from the library itself
Is this a know issue? and do you have a solution for this?
Example that triggers the warning when limit is
100ms
. It shows us 170ms is spent on type-checking this expressionThe overloading of functions
To give a better look, here is a snippet for the 3 overloaded functions extracted from SignalProtocol + Combining. The way they are written, they checking on error types for Element & O.