# Coinduction

The trait solver may use coinduction when proving goals. Coinduction is fairly subtle so we're giving it its own chapter.

## Coinduction and induction

With induction, we recursively apply proofs until we end up with a finite proof tree. Consider the example of `Vec<Vec<Vec<u32>>>: Debug` which results in the following tree.

- `Vec<Vec<Vec<u32>>>: Debug`
- `Vec<Vec<u32>>: Debug`
- `Vec<u32>: Debug`
- `u32: Debug`

This tree is finite. But not all goals we would want to hold have finite proof trees, consider the following example:

struct List<T> {
    value: T,
    next: Option<Box<List<T>>>,
}

For `List<T>: Send` to hold all its fields have to recursively implement `Send` as well. This would result in the following proof tree:

- `List<T>: Send`
- `T: Send`
- `Option<Box<List<T>>>: Send`
- `Box<List<T>>: Send`
- `List<T>: Send`
- `T: Send`
- `Option<Box<List<T>>>: Send`
- `Box<List<T>>: Send`
- ...

This tree would be infinitely large which is exactly what coinduction is about.

> To **inductively** prove a goal you need to provide a finite proof tree for it. To **coinductively** prove a goal the provided proof tree may be infinite.

While our implementation can not check for coninduction by trying to construct an infinite tree, as that would take infinite ressources, it still makes sense to think of coinduction from this perspective.

## Why do we need coinduction

We currently only consider auto-traits, `Sized`, and `WF`-goals to be coinductive. In the future we pretty much intend for all goals to be coinductive. It may not be clear why allowing coinductive proofs is even desirable.

### Recursive data types already rely on coinduction...

...they just tend to avoid them in the trait solver.

enum List<T> {
    Nil,
    Succ(T, Box<List<T>>),
}

impl<T: Clone> Clone for List<T> {
    fn clone(&self) -> Self {
        match self {
            List::Nil => List::Nil,
            List::Succ(head, tail) => List::Succ(head.clone(), tail.clone()),
        }
    }
}

We are using `tail.clone()` in this impl. For this we have to prove `Box<List<T>>: Clone` which requires `List<T>: Clone` but that relies on the currently impl which we are currently checking. By adding that requirement to the `where`-clauses of the impl, which is what we would do with [perfect derive], we move that cycle into the trait solver and [get an error][ex1].

### Recursive data types

We also need coinduction to reason about recursive types containing projections, e.g. the following currently fails to compile even though it should be valid.

use std::borrow::Cow;
pub struct Foo<'a>(Cow<'a, [Foo<'a>]>);

This issue has been known since at least 2015, see [#23714](https://github.com/rust-lang/rust/issues/23714) if you want to know more.

### Explicitly checked implied bounds

When checking an impl, we assume that the types in the impl headers are well-formed. This means that when using instantiating the impl we have to prove that's actually the case. [#100051](https://github.com/rust-lang/rust/issues/100051) shows that this is not the case. To fix this, we have to add `WF` predicates for the types in impl headers. Without coinduction for all traits, this even breaks `core`.

trait FromResidual<R> {}
trait Try: FromResidual<<Self as Try>::Residual> {
    type Residual;
}

struct Ready<T>(T);
impl<T> Try for Ready<T> {
    type Residual = Ready<()>;
}
impl<T> FromResidual<<Ready<T> as Try>::Residual> for Ready<T> {}

When checking that the impl of `FromResidual` is well formed we get the following cycle:

The impl is well formed if `<Ready<T> as Try>::Residual` and `Ready<T>` are well formed.
- `wf(<Ready<T> as Try>::Residual)` requires
- `Ready<T>: Try`, which requires because of the super trait
- `Ready<T>: FromResidual<Ready<T> as Try>::Residual>`, which has an impl which requires **because of implied bounds**
- `wf(<Ready<T> as Try>::Residual)` :tada: **cycle**

## Issues

There are some issues to keep in mind when dealing with coinduction.

### Implied super trait bounds

Our trait system currectly treats super traits, e.g. `trait Trait: SuperTrait`, by 1) requiring that `SuperTrait` has to hold for all types which implement `Trait`, and 2) assuming `SuperTrait` holds if `Trait` holds.

Relying on 2) while proving 1) is unsound. This can only be observed in case of coinductive cycles. Without a cycles, whenever we rely on 2) we must have also proven 1) without relying on 2) for the used impl of `Trait`.

trait Trait: SuperTrait {}

impl<T: Trait> Trait for T {}

// Keeping the current setup for coinduction
// would allow this compile. Uff :<
fn sup<T: SuperTrait>() {}
fn requires_trait<T: Trait>() { sup::<T>() }
fn generic<T>() { requires_trait::<T>() }

This is not really fundamental to coinduction but rather an existing property which is made unsound because of it.

#### Possible solutions

Always require a proof of `SuperTrait` when proving `Trait`. That is trivially correct and because at some point we actually have to prove `Trait`, and now `SuperTrait`, in an empty environment at which 2) cannot be used. This defacto means that both 1) and 2) can be removed as 1) is now generally meaningless due to 2) and we have to prove `SuperTrait` in all places which assume `Trait` anyways.

A different way to look at this would be to simply completely remove 2) and always elaborate `T: Trait` to `T: Trait` and `T: SuperTrait`. This would allow us to also remove 1), but as we still have to prove ordinary `where`-bounds on traits, that's just additional work.

While one could imagine ways to disable cyclic uses of 2) when checking 1), at least the ideas of myself - @lcnr - are all far to complex to be reasonable.

### `normalizes_to` goals and progress

A `normalizes_to` goal represents the requirement that `<T as Trait>::Assoc` normalizes to some `U`. This is achieved by defacto first normalizing `<T as Trait>::Assoc` and then equating the resulting type with `U`. It should be a mapping as each projection should normalize to exactly one type. By simply allowing infinite proof trees, we would get the following behavior:

trait Trait {
    type Assoc;
}

impl Trait for () {
    type Assoc = <() as Trait>::Assoc;
}

If we now compute `normalizes_to(<() as Trait>::Assoc, Vec<u32>)`, we would resolve the impl and get the associated type `<() as Trait>::Assoc`. We then equate that with the expected type, causing us to check `normalizes_to(<() as Trait>::Assoc, Vec<u32>)` again. This just goes on forever, resulting in an infinite proof tree.

This means that `<() as Trait>::Assoc` would be equal to any other type which is unsound.

#### How to solve this

**WARNING: THIS IS SUBTLE AND MIGHT BE WRONG**

Unlike trait goals, `normalizes_to` has to be *productive*[^1]. A `normalizes_to` goal is productive once the projection normalizes to a rigid type constructor, so `<() as Trait>::Assoc` normalizing to `Vec<<() as Trait>::Assoc>` would be productive.

A `normalizes_to` goal has two kinds of nested goals. Nested requirements needed to actually normalize the projection, and the equality between the normalized projection and the expected type. Only the equality has to be productive. A branch in the proof tree is productive if it is either finite, or contains at least one `normalizes_to` where the alias is resolved to a rigid type constructor.

Alternatively, we could simply always treat the equate branch of `normalizes_to` as inductive. Any cycles should result in infinite types, which aren't supported anyways and would only result in overflow when deeply normalizing for codegen.

experimentation and examples: https://hackmd.io/-8p0AHnzSq2VAE6HE_wX-w?view

Another attempt at a summary.
- in projection eq, we must make progress with constraining the rhs
- a cycle is only ok if while equating we have a rigid ty on the lhs after norm at least once
- cycles outside of the recursive `eq` call of `normalizes_to` are always fine

[^1]: related: https://coq.inria.fr/refman/language/core/coinductive.html#top-level-definitions-of-corecursive-functions

[perfect derive]: https://smallcultfollowing.com/babysteps/blog/2022/04/12/implied-bounds-and-perfect-derive
[ex1]: https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=0a9c3830b93a2380e6978d6328df8f72

## Meeting notes with niko

What are the properties our trait solver should ensure:

* Each time we can prove `T: Foo` (in any context), at monomorphization time we know that there is an impl of `Foo` for `T`
* and it's wellformed etc etc
* Associated type normalization always yields exactly one type (at monomorphization time)
* (`A::Item = X`, `A::Item = Y`, `X != Y`) => false -- we should be able to add this to the system and still never be able to prove false
* note: size may be infinite

At monomorphization time really means:

* For a ground term
* With an empty environment

Ground term means:

* No inference or other variables

Coinductive proof:

intuitively,

* you have some set of cases C0...Cn and you want to sure that the property P holds for all of them.
* if you can prove `P(Ci)` for all `i in 0..n` while assuming `P(Cj)` for all i != j, j in 0..n, then all of `P(C0...Cn)` holds
* and you can't prove false :)

in inductive case, you can order C0..Cn and prove it while assuming only `P(j)` for `j < i`. In coinductive case, there can be a set of cases that are either *all true* or *never true*.

Consider this case:

trait Trait {
    type Assoc;
}

impl Trait for () {
    type Assoc = Box<<() as Trait>::Assoc>;
}

The normalized type of `<() as Trait>::Assoc` is `Box<Box<Box<...>>>` (infinite in size). We don't prove finiteness so this is ok per the above properties (it will of course fail to compile for other reasons). (Think about that)

Can we prove that it is unique?

Consider two types, `T = Box<....>` and `Box<T>`, these are both infinite but `Box<T>` is a "bigger infinity"

* We can show that assuming `T` is unique, `Box<T>` is unique, by definition
* And we can show that `T` normalizes to `Box<T>` (handwavy), which is unique (previous case)