-
Notifications
You must be signed in to change notification settings - Fork 1.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
No workaround to dependent-type match types after SIP-56 #21402
Comments
Isn't there a way to work around using a cast, at least? |
fyi @patriknw |
Btw, the only reason your getInlined works is because val works2: Set[ActorRef[ReceptionistMessages.Listing[key.Protocol]]] = newState.subscriptions.getInlined(key) // workaround
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Found: Set[Subscriber[(key : AbstractServiceKey)]]
Required: Set[ActorRef[ReceptionistMessages.Listing[key.Protocol]]] The problem is these are type projections, reimplemented with match types. We have the same problem captured in tests/pos/i15155.scala, which is trying to reimplement import scala.language.`3.3` |
The fundamental abstraction we're missing here is lambdas from terms to types: class TypedMultiMap[T <: AnyRef, K <: (x: T) =>> Any]:
def get(key: T): Set[K(key)] = ???
transparent inline def getInlined(key: T): Set[K(key)] = ???
inline def inserted(key: T, value: K(key)): TypedMultiMap[T, K] = ???
object LocalReceptionist {
final case class State(
services: TypedMultiMap[AbstractServiceKey, x =>> ActorRef[x.Protocol]],
subscriptions: TypedMultiMap[AbstractServiceKey, x =>> ActorRef[ReceptionistMessages.Listing[x.Protocol]]
) I don't think there's a way to encode this currently ( |
How about with the new |
The context bound itself is a term parameter, for Singleton in particular it's an erased term parameter, but we still have the same issue about not being able to go from a term to a type |
@sjrd I'm looking at the spec (https://github.com/scala/improvement-proposals/pull/65/files), in lines 280-289:
The failures in the example are all |
Yes, I think I thought about that as well when I initially looked at the Pekko issue a while ago. AFAICT it should be sound, but it requires a new round of amending that SIP. |
…inees in match types. Previously, through the various code paths, we basically allowed type member extraction for stable scrutinees if the type member was an alias or a class member. In the alias case, we took the alias, whereas in the class case, we recreated a selection on the stable scrutinee. We did not allow that on abstract type members. We now uniformly do it for all kinds of type members. If the scrutinee is a (non-skolem) stable type, we do not even look at the info of the type member. We directly create a selection to it, which corresponds to what we did before for class members. We only try to dealias type members if the scrutinee type is not a stable type.
…inees in match types. Previously, through the various code paths, we basically allowed type member extraction for stable scrutinees if the type member was an alias or a class member. In the alias case, we took the alias, whereas in the class case, we recreated a selection on the stable scrutinee. We did not allow that on abstract type members. We now uniformly do it for all kinds of type members. If the scrutinee is a (non-skolem) stable type, we do not even look at the info of the type member. We directly create a selection to it, which corresponds to what we did before for class members. We only try to dealias type members if the scrutinee type is not a stable type.
…inees in match types. Previously, through the various code paths, we basically allowed type member extraction for stable scrutinees if the type member was an alias or a class member. In the alias case, we took the alias, whereas in the class case, we recreated a selection on the stable scrutinee. We did not allow that on abstract type members. We now uniformly do it for all kinds of type members. If the scrutinee is a (non-skolem) stable type, we do not even look at the info of the type member. We directly create a selection to it, which corresponds to what we did before for class members. We only try to dealias type members if the scrutinee type is not a stable type.
…inees in match types. Previously, through the various code paths, we basically allowed type member extraction for stable scrutinees if the type member was an alias or a class member. In the alias case, we took the alias, whereas in the class case, we recreated a selection on the stable scrutinee. We did not allow that on abstract type members. We now uniformly do it for all kinds of type members. If the scrutinee is a (non-skolem) stable type, we do not even look at the info of the type member. We directly create a selection to it, which corresponds to what we did before for class members. We only try to dealias type members if the scrutinee type is not a stable type.
… in match types. (#21700) Previously, through the various code paths, we basically allowed type member extraction for stable scrutinees if the type member was an alias or a class member. In the alias case, we took the alias, whereas in the class case, we recreated a selection on the stable scrutinee. We did not allow that on abstract type members. We now uniformly do it for all kinds of type members. If the scrutinee is a (non-skolem) stable type, we do not even look at the info of the type member. We directly create a selection to it, which corresponds to what we did before for class members. We only try to dealias type members if the scrutinee type is not a stable type.
Based on the problem found in
akka/akka
andapache/pekko
In the snippet we can come up with workaround to
TypedMultiMap.get
by usingtransparent inline
however there seems to be no workaround for theTypedMultiMap.inserted
method.Compiler version
All Scala 3.4+ versions
Minimized code
Output
Expectation
This kind of issues might pop-up more often as projects would migrate to Scala 3.4+. It would be great if we could propose some workarounds that would allow for their compilation..
The text was updated successfully, but these errors were encountered: