Evaluate usage and need of Kind::Any

[michaeljklein]

Problem

Kind::Any was implicitly added (as None: Option<Kind>) in #5837 and is explicitly added in #6094

It's a Kind that unifies with all other Kinds and thus can reduce how much type safety we achieve by using Kind's.

Happy Case

1. Resolve whether Kind::Any is required in the first place:

a. It seems that Kind::Any, or a roughly equivalent Kind::Unresolved, is required for _ types, e.g.

let x: Field = 3;
let z: _ = x;

b. Unspecified types, i.e. a UnresolvedTypeData::Unspecified that's filled in later, also use Kind::Any as of #6094

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

2. 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?

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

[michaeljklein]

Relevant issue and PR:

• Compiler doesn't infer generics on Field::from_be_bytes correctly #6188
• fix: type variables by default should have Any kind #6203