Consider reintroducing method specific type parameter bounds

[Yorick Peterse]

Description

Inko used to allow you to write code such as this:

impl Array {
  fn foo(...) if T: SomeTrait { ... }
}

This was removed in favour of moving the if to the impl as a whole, rather than a specific method. For traits this can lead to a problem where a method can't be defined in the trait if it needs more requirements than the trait as a whole. The prime example of this is String.join: it requires an iterator that yields ToString values, but we can't express that in the definition of the Iter trait. This inconsistency is a bit odd, especially given to_array is defined on the Iter trait. If we were to allow if on methods again, join would just be an instance method on Iter with the signature fn pub move join(with: String) -> String if T: ToString { ... }.

Implementation wise, if a method in a trait were to specify any type parameter bounds, and so does the implementation of the trait, then the final bounds are the union of the two. Duplicate requirements are ignored as to allow code such as this:

trait Foo[T] {
  fn whatever if T: Bla { ... }
}

class Bar[B] { ... }

impl Foo for Bar if B: Bla + Quix {
  fn whatever { ... }
}

If the implemented method doesn't specify any bounds, it inherits them from the trait, meaning you can't remove bounds. If an if is specified, then the bounds are the result of the union of the method definition in the trait, the bounds of the impl, and the bounds of the method implementation:

trait Foo[T] {
  fn whatever if T: A { ... }
}

class Bar[T] { ... }

impl Foo for Bar if T: B {
  fn whatever if T: C { ... }
}

Here Bar.whatever has the bounds T: A + B + C.

Related work

No response