Raku cloned object not sunk

Question

class A {
  has $.n;

# If this method is uncommented then the clone won't be sunk  
#  method clone {
#    my $clone = callwith(|%_);
#    return $clone;
#  }

  method sink(-->Nil) { say "sinking...$!n" }
}

sub ccc(A:D $a) { $a.clone(n=>2) }

ccc(A.new(n=>1));
say 'Done';

Above prints:

sinking...2
Done

However, if the custom clone method is used, then the returned clone from ccc won't be sunk for some reason. It works if I sink it explicitly at call site or if I change the my $clone = callwith(|%_) line to my $clone := callwith(|%_). Is this expected? What's the reason that it's working this way?

Thanks!

Answer 1

There are lots of filed-and-still-open-years-later sink bugs (and, I suspect, loads that have not been filed).

As touched on in my answer to Last element of a block thrown in sink context:

someone needs to clean the kitchen sink, i.e. pick up where Zoffix left off with his Flaws in implied sinkage / &unwanted helper issue.

Zoffix's conclusion was:

So given there are so many issues with the system, I'm just wondering if there isn't a better one that can be used to indicate whether something is wanted or not.

Fast forward 2 years, and a better system is hopefully going to land. In a recent grant report jnthn writes:

The current code doing this work in Rakudo is difficult to follow and not terribly efficient. ... Since RakuAST models the language at a higher level and defers producing QAST until much later, a far cleaner solution to the sink analysis problem is possible. ... I'm optimistic that the model I've created will be flexible enough to handle all the sinking-related requirements

Answer 2

I'm not sure what is going on yet, but removing the return statement makes the cloned object call the right sink method.

I've created an issue for it: https://github.com/rakudo/rakudo/issues/3855