You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Split out of #6320. This issue should stick to concrete examples and practical motivations (I'm looking at you @sstucki π ) β longer-winded discussion should stick to #6320; we have an idea on how to fix this, but it might require significant changes to the subtype typechecker β threading an expected kind when comparing types. /cc @smarter. Once we have the best example we can come up with, I'd propose to tag others, e.g. Miles and Martin.
In Scala, when checking that Ξ β’ F T1 <: F T2 (for some F), we might be too conservative, because T1 <: T2 might be false in general, but true under the context induced by F. For instance, [X] => [Y] => X <: [X] => [Y] => Y is false in general, but true under the right bounds. For an artificial example, as arguments of Foo.F below.
That code fails to compile today in either Scala or Dotty due to this issue.
Question: better motivation
Is anybody aware of have less artificial examples? I don't know any, and honestly it does not seem a priority, but as @sstucki spent some time arguing for this in theory, so I felt I should try to make the strongest and shortest case I could for it. I'm not yet happy with this, but it's progress.
The text was updated successfully, but these errors were encountered:
Blaisorblade
changed the title
Subtype checking of type lambdas with bounds is too restrictive
Subtype checking of type lambdas with bounds is too restrictive, part 2
May 12, 2019
Not really sure what the point of this issue is, but here's a slightly less silly example adapted from the OP (comment):
traitStillPrettySilly {
typeAppInt[+F[X<:Int]] // could be defined as F[Int]typeEtaExp[F[_]] = [X<:Int] =>F[X]
typeListUnbounded[X] =List[X]
typeListBounded[X<:Int] =List[X]
vallu:AppInt[ListUnbounded]
vallb:AppInt[ListBounded]
// These should all work -- eta-expansion should not matter!vallb1:AppInt[ListBounded] = lu // OKvallu1:AppInt[ListUnbounded] = lb // failsvalleu:AppInt[EtaExp[ListUnbounded]] = lb // OK
}
Uh oh!
There was an error while loading. Please reload this page.
Split out of #6320. This issue should stick to concrete examples and practical motivations (I'm looking at you @sstucki π ) β longer-winded discussion should stick to #6320; we have an idea on how to fix this, but it might require significant changes to the subtype typechecker β threading an expected kind when comparing types. /cc @smarter. Once we have the best example we can come up with, I'd propose to tag others, e.g. Miles and Martin.
In Scala, when checking that
Ξ β’ F T1 <: F T2
(for someF
), we might be too conservative, becauseT1 <: T2
might be false in general, but true under the context induced byF
. For instance,[X] => [Y] => X <: [X] => [Y] => Y
is false in general, but true under the right bounds. For an artificial example, as arguments ofFoo.F
below.That code fails to compile today in either Scala or Dotty due to this issue.
Question: better motivation
Is anybody aware of have less artificial examples? I don't know any, and honestly it does not seem a priority, but as @sstucki spent some time arguing for this in theory, so I felt I should try to make the strongest and shortest case I could for it. I'm not yet happy with this, but it's progress.
Transcripts
The text was updated successfully, but these errors were encountered: