c. std::meta::fresh_type_variable currently produces a type variable with Kind::Any
To prevent a breaking change, we could add std::meta::fresh_type_variable_with_kind(kind: Kind) -> Type
If a breaking change to avoid Kind::Any is preferable, change the type of std::meta::fresh_type_variable to std::meta::fresh_type_variable(kind: Kind) -> Type
Note that the above changes require a reflection of Kind into the stdlib
How would a Kind::Unresolved be different from Kind::Any?
Perhaps we could throw an error if a Kind::Any/Kind::Unresolved is reached during monomorphization?
Though a Kind::Unresolved might be able to occur in valid code at monormophization if a _-typed variable is completely unused.
How can we tell that a Kind::Unresolved has reached a point where it must be resolved, since it's likely to be resolved during an arbitrary stage of unification and may not be resolved if unused?
Problem
Kind::Any
was implicitly added (asNone: Option<Kind>
) in https://github.com/noir-lang/noir/pull/5837 and is explicitly added in https://github.com/noir-lang/noir/pull/6094It's a
Kind
that unifies with all otherKind
s and thus can reduce how much type safety we achieve by usingKind
's.Happy Case
Resolve whether
Kind::Any
is required in the first place:a. It seems that
Kind::Any
, or a roughly equivalentKind::Unresolved
, is required for_
types, e.g.b. Unspecified types, i.e. a
UnresolvedTypeData::Unspecified
that's filled in later, also useKind::Any
as of https://github.com/noir-lang/noir/pull/6094c.
std::meta::fresh_type_variable
currently produces a type variable withKind::Any
std::meta::fresh_type_variable_with_kind(kind: Kind) -> Type
Kind::Any
is preferable, change the type ofstd::meta::fresh_type_variable
tostd::meta::fresh_type_variable(kind: Kind) -> Type
Kind
into the stdlibHow would a
Kind::Unresolved
be different fromKind::Any
?Kind::Any
/Kind::Unresolved
is reached during monomorphization?Kind::Unresolved
might be able to occur in valid code at monormophization if a_
-typed variable is completely unused.Kind::Unresolved
has reached a point where it must be resolved, since it's likely to be resolved during an arbitrary stage of unification and may not be resolved if unused?Workaround
None
Workaround Description
No response
Additional Context
No response
Project Impact
Nice-to-have
Blocker Context
No response
Would you like to submit a PR for this Issue?
None
Support Needs
No response