Allow refinements that refine already refined types. #244
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Previously, a double definition errorfor `T` was produced in a case like this:
type T1 = C { T <: A }
type T2 = T1 { T <: B }
This was caused by the way T1 was treated in the refinement class
that is used to typecheck the type. Desugaring of T2 with `refinedTypeToClass`
would give
trait <refinement> extends T1 { type T <: B }
and `normalizeToClassRefs` would transform this to:
trait <refinement> extends C { type T <: A; type T <: B }
Hence the double definition. The new scheme desugars the rhs of `T2` to:
trait <refinement> extends C { this: T1 => type T <: B }
which avoids the problem.
Also, added tests that scala#232 (fix/boundsPropagation) indeed considers all refinements
together when comparing refined types.
| case tp: RefinedType if tp.argInfos.nonEmpty => tp // parameterized class type | ||
| case tp: TypeRef if tp.symbol.isClass => tp // monomorphic class type | ||
| case tp: TypeProxy => stripToCore(tp.underlying) | ||
| case _ => defn.AnyType |
There was a problem hiding this comment.
Was this changed intentionally from Object to Any? If so, why?
There was a problem hiding this comment.
Yes that was intentional. It seems that Any is the more natural parent type for a purely structural type.
There was a problem hiding this comment.
Agreed. I remember this coming up as a rough edge between value classes and structural types:
scala> trait T extends Any { def t }
defined trait T
scala> def foo(c: { def t} ) = c.t
warning: there was one feature warning; re-run with -feature for details
foo: (c: AnyRef{def t: Unit})Unit
scala> def test(t: T) = foo(t)
<console>:9: error: type mismatch;
found : t.type (with underlying type T)
required: AnyRef{def t: Unit}
def test(t: T) = foo(t)
^
It would be interesting to experiment with changing this in scalac and running the community build to find out how compatible it is.
|
LGTM. |
|
Yes, I think the reason for AnyRef parent for structural types is historical. Structural types came before value classes and were represented as traits. Since traits could not have an Any parent then, it was logical to pick AnyRef. |
odersky
added a commit
that referenced
this pull request
Nov 26, 2014
Allow refinements that refine already refined types.
OlivierBlanvillain
pushed a commit
to OlivierBlanvillain/dotty
that referenced
this pull request
Dec 12, 2016
tgodzik
added a commit
to tgodzik/scala3
that referenced
this pull request
Apr 29, 2025
Backport "Fix copy of annotation on @main methods" to 3.3 LTS
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Previously, a double definition errorfor
Twas produced in a case like this:This was caused by the way T1 was treated in the refinement class
that is used to typecheck the type. Desugaring of T2 with
refinedTypeToClasswould give
and
normalizeToClassRefswould transform this to:Hence the double definition. The new scheme desugars the rhs of
T2to:which avoids the problem.
Also, added tests that #232 (fix/boundsPropagation) indeed considers all refinements
together when comparing refined types.
Supersedes #243. Review by @retronym please.