Remove ambiguities from TASTy reflect interface #6191
Conversation
nicolasstucki
changed the title
| tpd.cpy.RefinedTypeTree(original)(tpt, refinements) | ||
|
|
||
| type TypeTree_Applied = tpd.AppliedTypeTree | ||
| type Applied = tpd.AppliedTypeTree |
There was a problem hiding this comment.
Should it be TypeApplied?
There was a problem hiding this comment.
Will do this renaming after #6193 for simplicity
| * | +- ByName | ||
| * | +- LambdaTypeTree | ||
| * | +- TypeBind | ||
| * | +- TypeBlock |
There was a problem hiding this comment.
This refactoring reminds me of a disagreement among @xeno-by @odersky @olafurpg and me about whether type trees and types should be the same.
Now opinions seem to converge that they should not be the same, as it's implemented in Tasty Reflect. However, I think one issue left unaddressed: the confusion to meta programmers why there are seemingly overlapping Types and TypeTrees and usability problems evidenced by this PR.
To address the usability issue, I propose to just have one abstract type TypeTree (which could be used for positions) and remove all APIs to extract or construct TypeTree. Instead, meta-programmers should always work with Types, which is more reliable, as we do in the compiler.
Just a thought for discussion, no need to address in this PR.
|
|
||
| /** Type tree representing a type refinement */ | ||
| type TypeTree_Refined <: TypeTree | ||
| type Refined <: TypeTree |
There was a problem hiding this comment.
It's called Refinement in Type, do we need some consistency here?
There was a problem hiding this comment.
Will do this renaming after #6193 for simplicity
ghost
removed
the
To avoid awkward imports like in https://github.com/lampepfl/dotty/pull/6042/files#diff-c60b7bdb36081577552ac360877d74ebR49