# `Const`'s `ty` field, what is it good for

## Random information

The `ty` field on const stores what kind the const parameter is (note: this is intended to be the type theory meaning of a generic kind, not to be confused with `ConstKind`). When using a `Const` argument we have to ensure that the provided arg is of the same type/kind as the actual param:

fn foo<const N: u8>() {}

fn bar() {    
    foo::<10_u16>();
}
//~^ should error because providing a `u16` value to a `u8` const param
//    is not legal

The `bar` item does not actually perform any checks that the correct kinds of const parameters are provided as arguments.

Every const generic argument is desugared to an anonymous const item which is typeck'd separately from its parent item. When typeck'ing the const item the return type is set to the type of the const param it is an argument for.

An exception to this is arguments that are being inferred, either via the `generic_arg_infer` feature or when generics in paths have been elided. These do not have anon consts.

We currently do not relate the `ty` field when relating consts, instead we just ICE if the two `ty`'s compared via `PartialEq` are not the same.

---

If we were to support directly using const items (i.e. assoc consts) as const arguments for a `min_generic_const_exprs`(`mgce`) (i.e. `foo::<<T as Trait<_>>::ASSOC>()`) There would no longer be an anon const getting typeck'd and we would need to actually check that the types of const arguments are correct.

---

If we were to support const generics that have types that depend on other generics it would be valuable to allow "forward declared" types of const params, i.e. `struct Foo<const N: T, T>`, as otherwise you could not have a non-defaulted const parameter of a type that has default i.e. `struct Foo<const N: T, T = u32>`. This would mean we are no longer able to construct the expected ty of the const arg during ast lowering for the substs, it would only be available once they have all been built.

Allowing this would make the current planned query feeding solution for typechecking anonymous constants inadequate as we would be able to end up with infer vars in the expected type and we are unable to have infer vars in query inputs/outputs:

fn foo<T, const N: T>() -> T { N }

fn main() {
    let mut a = foo::<_, { 1 }>();
    //                   ^^^^^ expected type would be `_`
    a = 1_u8;
}

If we're allowing `const N: T, T`, as previously mentioned, we would not even be able to construct the expected type to feed even if it did not contain infer vars, i.e. `foo::<{ 1 }, u8>()`.

Additionally it would be nice if the following were to compile:

fn foo<const N: T, T = bool>() {}

fn main() {
    foo::<{ 1_u8 }, _>();
}

This would require inferring the type infer var to `u8` by typechecking the anon const.

---

Currently `super_relate_consts` has an assertion that both `Const`'s have the same `ty`. This is at first was implemented via just `==` but this is inadequate.

With `adt_const_params` we can have const/type aliases in the `ty` which makes `==` spurriously return false leading to ICEs. type alises are eagerly normalized at the moment so only const aliases which use lazy norm cause problems. To fix this we currently call `normalize_erasing_regions` in `super_relate_consts` before `==`.

Under `mgce` or `T, const N: T` we wil start getting infer vars in the `ty` at which point this will also start spurriously ICEing because of things like `?0 == ?1` not being true even though they might end up getting constrained by the end of the type relation.

This assertion has caught many bugs so keeping it in some form will be valuable so just flat out removing it is not desirable.

---

## Changes to make

A `ConstParamHasType` obligation that requires a `Const` have a type equal to some `Ty` would potentially solve two issues that mgce would have:
- Would actually check that provided args are of the correct type
- Is checked after substs are built allowing forward declared const parameter types

And as outlined in [pcg-44](https://github.com/rust-lang/project-const-generics/issues/44):
- Would allow for less error prone trait/impl checks (a win for even min const generics)

Implemented in [#107965](https://github.com/rust-lang/rust/pull/107965)

---

Note: dont actually know if this is possible or not :upside_down_face: It seems tricky to do

Start type checking anon consts as part of the parent body and lower anon const const args to infer vars. When the anon const has been fully type checked use query feeding to create the defid for the anon const and relate a `ConstKind::Unevaluated` with the previously created infer var. This should be "necessary" even without supporting generic anon consts i.e. `N + 1`. Just supporting `fn foo<const N: T, T>` and `foo::<{ 1_u8 }, _>();` will likely need this.

- This should allow for the desired type inference quality where type checking the anon const can infer the return type and type checking the function can infer the anon const's return type.
- Sidesteps the problem of not having the expected type available during astconv of substs as we only actually create the anon const once the return type has been inferred
- Don't have to deal with infer vars in the `type_of` returned value as we only create the anon const after the return type has been inferred

Not yet implemented

---

Change the assertion in `super_relate_consts` from `a_ty == b_ty` to instead actually relate the two tys inside of a probe and ICE if it returns an error.

- It's important to do it inside of a probe as this assertion should not help code to compile.
- The assertion likely will not catch every mistake as it will succeed for `?0 eq ?1` even if we never actually relate the two infer vars outside of the probe

Implemented in [#107940](https://github.com/rust-lang/rust/pull/107940)