arrow-types.md

Arrow Types aka Viewpoints

When we talked about reference capability composition and viewpoint adaptation, we dealt with cases where we know the reference capability of the origin. However, sometimes we don't know the precise reference capability of the origin.

When that happens, we can write a viewpoint adapted type, which we call an arrow type because we write it with an ->.

Using this-> as a viewpoint

A function with a box receiver can be called with a ref receiver or a val receiver as well since those are both subtypes of box. Sometimes, we want to be able to talk about a type to take this into account. For example:

class Wombat
  var _friend: Wombat

  fun friend(): this->Wombat => _friend

Here, we have a Wombat, and every Wombat has a friend that's also a Wombat (lucky Wombat). In fact, it's a Wombat ref, since ref is the default reference capability for a Wombat (since we didn't specify one). We also have a function that returns that friend. It's got a box receiver (because box is the default receiver reference capability for a function if we don't specify it).

So the return type would normally be a Wombat box. Why's that? Because, as we saw earlier, when we read a ref field from a box origin, we get a box. In this case, the origin is the receiver, which is a box.

But wait! What if we want a function that can return a Wombat ref when the receiver is a ref, a Wombat val when the receiver is a val, and a Wombat box when the receiver is a box? We don't want to have to write the function three times.

We use this->! In this case, this->Wombat. It means "a Wombat ref as seen by the receiver".

We know at the call site what the real reference capability of the receiver is. So when the function is called, the compiler knows everything it needs to know to get this right.

Using a type parameter as a viewpoint

We haven't covered generics yet, so this may seem a little weird. We'll cover this again when we talk about generics (i.e. parameterised types), but we're mentioning it here for completeness.

Another time we don't know the precise reference capability of something is if we are using a type parameter. Here's an example from the standard library:

class ListValues[A, N: ListNode[A] box] is Iterator[N->A]

Here, we have a ListValues type that has two type parameters, A and N. In addition, N has a constraint: it has to be a subtype of ListNode[A] box. That's all fine and well, but we also say the ListValues[A, N] provides Iterator[N->A]. That's the interesting bit: we provide an interface that let's us iterate over values of the type N->A.

That means we'll be returning objects of the type A, but the reference capability will be the same as an object of type N would see an object of type A.

Using box-> as a viewpoint

There's one more way we use arrow types, and it's also related to generics. Sometimes we want to talk about a type parameter as it is seen by some unknown type, as long as that type can read the type parameter.

In other words, the unknown type will be a subtype of box, but that's all we know. Here's an example from the standard library:

interface Comparable[A: Comparable[A] box]
  fun eq(that: box->A): Bool => this is that
  fun ne(that: box->A): Bool => not eq(that)

Here, we say that something is Comparable[A] if and only if it has functions eq and ne and those functions have a single parameter of type box->A and return a Bool. In other words, whatever A is bound to, we only need to be able to read it.