Extend automatic receiver recovery to include arguments as recovery candidates.

[jemc]

In this week's sync call, @Praetonus mentioned that the compiler is missing out on recognizing some constructs as safe.

Particularly, he noted that the current rule for automatic receiver recovery is more restrictive than it needs to be.

The gist of the current rule is that we can automatically recover the receiver if all the arguments and the return value are sendable. @Praetonus mentioned that this rule could be tweaked to allow recovering one of the arguments instead, if the receiver and all other arguments are sendable. This makes sense in the context of thinking about the receiver in Pony as being just another argument to the function.

The purpose of this ticket is to discuss and track work for that rule enhancement.

[jemc]

@jasoncarr0 says there may be issues evaluation order of the receiver argument vs the other arguments, and the causing of invalidation.

[jasoncarr0]

Example where there's an issue with evaluation order as brought up wrt ponylang/rfcs#182

class Foo
  fun val a_method(other: Foo ref): Bool =>
     this == other
     
class Bar
  var foo: Foo iso
  fun ref getAsVal(): Foo val =>
     foo = Foo

actor Main new create(env: Env) =>
  let bar = Bar
  bar.getAsVal().a_method(bar.foo)

Under Pony's arguments-first evaluation order, we first grab a temporary iso alias to bar.foo, then getAsVal() gives us a val alias which aliases, so we can do any amount of "bad things" by passing sendables (e.g. sending the val to another actor and then modifying)

[jemc]

Thanks for the great succinct example.

Given that this would be unsafe to allow under current Pony semantics, I'll close this issue, and any further discussion on related topics, new semantics, and how to prove safety of things like this can take place in RFCs.

[jemc]

@jasoncarr0 - Thinking about this more, maybe we can trivially allow this as long as the receiver is a local variable (rather than a more complex expression)? That would force the user to evaluate a complex receiver expression first (by assigning it to a local variable), avoiding the issue with order of evaluation and still allowing a lot of useful cases.