`TyKind` Variants Continued, Import Conventions, and Type Errors

“substitutions”, etc). There are many variants on the `TyKind` enum, which you can see by looking at its [documentation][tykind]. Here is a sampling: - [**Algebraic Data Types (ADTs)**][kindadt] An [*algebraic data type*][wikiadt] is a `struct`, `enum` or `union`. Under the hood, `struct`, `enum` and `union` are actually implemented the same way: they are all [`ty::TyKind::Adt`][kindadt]. It’s basically a user defined type. We will talk more about these later. - [**Foreign**][kindforeign] Corresponds to `extern type T`. - [**Str**][kindstr] Is the type str. When the user writes `&str`, `Str` is the how we represent the `str` part of that type. - [**Slice**][kindslice] Corresponds to `[T]`. - [**Array**][kindarray] Corresponds to `[T; n]`. - [**RawPtr**][kindrawptr] Corresponds to `*mut T` or `*const T`. - [**Ref**][kindref] `Ref` stands for safe references, `&'a mut T` or `&'a T`. `Ref` has some associated parts, like `Ty<'tcx>` which is the type that the reference references. `Region<'tcx>` is the lifetime or region of the reference and `Mutability` if the reference is mutable or not. - [**Param**][kindparam] Represents a type parameter (e.g. the `T` in `Vec<T>`). - [**Error**][kinderr] Represents a type error somewhere so that we can print better diagnostics. We will discuss this more later. - [**And many more**...][kindvars] ## Import conventions Although there is no hard and fast rule, the `ty` module tends to be used like so: ```rust,ignore use ty::{self, Ty, TyCtxt}; ``` In particular, since they are so common, the `Ty` and `TyCtxt` types are imported directly. Other types are often referenced with an explicit `ty::` prefix (e.g. `ty::TraitRef<'tcx>`). But some modules choose to import a larger or smaller set of names explicitly. ## Type errors There is a `TyKind::Error` that is produced when the user makes a type error. The idea is that we would propagate this type and suppress other errors that come up due to it so as not to overwhelm the user with cascading compiler error messages. There is an **important invariant** for `TyKind::Error`. The compiler should **never** produce `Error` unless we **know** that an error has already been reported to the user. This is usually because (a) you just reported it right there or (b) you are propagating an existing Error type (in which case the error should've been reported when that error type was produced).

This section continues the discussion of `TyKind` variants, including Ref, Param, Error, and others. It then outlines common import conventions for the `ty` module, specifically highlighting the frequent direct import of `Ty` and `TyCtxt`. Finally, it describes the purpose of `TyKind::Error` for handling type errors, emphasizing the invariant that it should only be produced after an error has already been reported to the user to prevent cascading error messages.