Aliasing objects with uniqueness refcap constraint by method invocation

[Schwarzbaer]

https://github.com/ponylang/pony-tutorial/blob/master/capabilities/aliasing.md#what-counts-as-making-an-alias states (point 3) that calling an object's method creates an alias, this, of that object. That seems to imply that an iso object either can't have its method called, or that the this will be a tag, both of which sound unlikely. The whole matter of method invocation interacting with reference capability feel a bit under-documented.

[mfelsche]

I do think covering method invocation in greater detail with respect to capabilities in the Aliasing section does make sense.

Just to get this out quickly before the tutorial section is written: @TheCheapestPixels if you have a type T with a function fun ref my_fun() then inside this function this will be of type T ref!, effectively T ref, as we have a ref receiver. If T would have a fun iso my_iso_fun() it can only be called on T iso objects and inside of it this will be T iso! - thus effectively T tag.

To make matters worse, there is also: https://tutorial.ponylang.org/capabilities/recovering-capabilities.html#automatic-receiver-recovery

[Praetonus]

This isn't exactly true. The receiver inside of a function is what the receiver capability says it is. So the receiver in a fun iso is iso. This means that you can only call an iso function on an iso^ receiver (iso and iso^ can be substituted with trn and trn^ in everything I say here).

iso functions are mostly used when automatic receiver recovery isn't applicable, e.g. if some of your arguments aren't sendable. The usual pattern is to return the receiver, so that the caller can consume it when calling the function and then get it back as the return value. There is an example of that with String.add, which internally uses String._append and looks like this:

class String
  fun add(that: String box): String val =>
    let s: String iso = recover String end
    (consume s)._append(this)._append(that)

  fun iso _append(s: String box): String iso^ =>
    /* Implementation code to append the new String
     * ...
     */
    consume this

I agree that the tutorial section does need to be updated with more details, especially considering that even you got confused @mfelsche.

[rhagenson]

Is this covered by #449? If not, can/should it be included there?

@jasoncarr0 What are your thoughts on including a resolution on this issue with your PR?

[jasoncarr0]

This is touched upon but not exactly covered in #449 as it doesn't go into much detail about function receivers, and probably could use a bit more work around what causes aliasing. I think it's definitely worthwhile to roll in, although it won't be able to be merged until we can get PRs merged for ponyc

[rhagenson]

This addition is low enough priority/maintenance that the fix being held off a bit longer is okay in my opinion.

@jasoncarr0 Do you have an idea of where/how to include this with #449? Anyway I can help beyond reviewing once this is included?

[jasoncarr0]

@rhagenson I'd have to think about where this could fit. In effect I'd expect this needs to be in a section that describes receiver capabilities or "formally" describes what is actually aliasing. Tbh those could well be made independent.

While looking at this I noticed there's a slight explanation around automatic receiver recovery:

Automatic receiver recovery

When you have an iso or trn receiver, you normally can’t call ref methods on it. That’s because the receiver is also an argument to a method, which means both the method body and the caller have access to the receiver at the same time. And that means we have to alias the receiver when we call a method on it. The alias of an iso is a tag (which isn’t a subtype of ref) and the alias of a trn is a box (also not a subtype of ref).

Realizing this section may also need to be updated anyway (if only to clean up the iso being a subtype of ref part)

[rhagenson]

I'd have to think about where this could fit. In effect I'd expect this needs to be in a section that describes receiver capabilities or "formally" describes what is actually aliasing. Tbh those could well be made independent.

Are you meaning independent sections, or independence between receiver capabilities and aliasing?

Re: automatic receiver recovery. Looking at that same section I want to rewrite it for clarity anyhow so if this fix is not rolled into your PR then I can handle it on a rewrite.

[jasoncarr0]

I believe I was referring to independence from my changes. But in some sense they're nearly independent from each other as well.