simplify instantiation of generic types (semtypinst
)
#846
Labels
compiler/sem
Related to semantic-analysis system of the compiler
simplification
Removal of the old, unused, unnecessary or un/under-specified language features.
Milestone
Goal
Have
semtypinst
only produce fully resolved non-meta types (i.e., types that don't contain any unresolved generic parameters, type-classes,any
, etc.).Why?
At present, the type parameter application implemented in
semtypinst
supports two modes: with meta-types and without (signaled by theallowMetaTypes
option). The largest differences between both modes is that in "meta-types allowed" mode:exactReplica
) instead of proper onesModuleGraph
state (e.g., hooks) is disabledA different way to look at the "allow meta-type" mode is that it allows for replacing type variables while some of them may be still unknown.
Two problems that arise from this:
semtypinst
, which makes the code very non-linear, and thus hard to followsemtypinst
in "meta-types allowed" are improper ones, whose presence complicates other things (for example, thesameObjectType
logic, which now can't rely on ID comparisons)The reason for meta-
tyGenericInst
types existing seems to mainly be for the convenience oftypeRel
, which lacks proper support for unappliedtyGenericInvocation
s (atyGenericInst
is effectively an evaluatedtyGenericInvocation
).Concrete benefits
Not having the "allow meta-type" mode would significantly simplify the logic in
semtypinst
and make the code easier to reason about. In addition:tyGenericInst
would change to always represent fully resolved non-meta typesexactReplica
usages are likely going to be still required, a lot of them can removedBoth, in turn, would either help with or make possible further improvements to
semtypinst
and other type-related fixes.How?
Removing the "meta-types allowed mode" will first require moving all of its users. These are (in no specific order):
instGenericContainer
usage when turning atyGenericBody
into atyCompositeTypeClass
. Done: internal: keep composite type-classes unresolved #864instGenericContainer
usage for instantiating generic concepts. Done: internal: don't instantiate concepts when lifting types #861prepareMetatypeForSigmatch
intryGenerateInstance
. Done: internal: improvetryGenerateInstance
#858prepareMetatypeForSigmatch
intypeRel
. Done: typerel: reworktyGenericInvocation
handling #854replaceTypesInBody
intryResolvingStaticExpr
. Done: better dependent-expression support for range types #850Many of the aforementioned boil down to duplicating and adjusting the relevant
replaceTypeVarsT
andhandleGenericInvocation
parts into standalone procedures.The text was updated successfully, but these errors were encountered: