Introduce workaround (in fact, fix the previously incorrect expect-ac… #3850
Conversation
…tual mapping) for CancellationException. See KT-61168
| @kotlin.internal.LowPriorityInOverloadResolution | ||
| public actual fun CancellationException(message: String?, cause: Throwable?): CancellationException = | ||
| CancellationException(message, cause) |
There was a problem hiding this comment.
Is this LowPriorityInOverloadResolution just to make this definition work, or is it also so that platform-specific code chooses the other overload?
- If it's for the definition to work, won't a fully-qualified name work better? Like
= kotlin.coroutines.cancellation.CancellationException(message, cause). - If it's for choosing the other overload, maybe we can ensure this also happens on K2 by marking this function as
inline? Is this possible?
There was a problem hiding this comment.
To make the declaration work (otherwise, it's conflicting overloads on the declaration level) and, later, the choice of the overload from our/users' code.
maybe we can ensure this also happens on K2 by marking this function as inline?
It's a bit unclear to me what you've meant, could you please elaborate on that?
There was a problem hiding this comment.
It's a bit unclear to me what you've meant, could you please elaborate on that?
If I remember correctly, with K2, in common code, the overload that gets chosen in the end is the common one, so in this case, the expect function. If that's undesirable, can't we mark this function as inline instead so its calls always get converted to the ones we want?
There was a problem hiding this comment.
I see, thanks.
the overload that gets chosen in the end is the common one
Unfortunately, it will be the case only for the code in kotlinx-coroutines-core sourceset and not for our users, so I don't think it worth it
|
Ok, now I got it. It is as good as it gets, I think. |
…tual mapping) for CancellationException.
See KT-61168 for the root cause & KT-22004 for the future solution