Клонированный объект Раку не затонул

Aug 20 2020

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';

Выше отпечатки:

sinking...2
Done

Однако, если используется специальный cloneметод, то возвращенный клон cccпо какой-то причине не будет потоплен. Это сработает, если я sinkвыберу его явно на сайте вызова или если я изменю my $clone = callwith(|%_)строку на my $clone := callwith(|%_). Ожидается ли это? В чем причина того, что это так работает?

Благодаря!

Ответы

3 raiph Aug 21 2020 at 07:21

Есть много зарегистрированных и открытых годами ошибок ошибок (и, я подозреваю, грузов, которые не были зарегистрированы).

Как уже упоминалось в моем ответе на последний элемент блока, брошенного в контексте приемника :

кому-то нужно очистить кухонную раковину, то есть продолжить с того места, где остановился Зоффикс с его недостатками в предполагаемом затоплении / и нежелательной проблемой помощника .

Заключение Зоффикса было:

Итак, учитывая, что с системой так много проблем, мне просто интересно, нет ли лучшего, что можно было бы использовать, чтобы указать, нужно ли что-то или нет.

Перенесемся на 2 года вперед, и мы надеемся, что появится лучшая система. В недавнем отчете о гранте jnthn пишет:

Текущий код, выполняющий эту работу в Rakudo, труден для понимания и не очень эффективен. ... Поскольку RakuAST моделирует язык на более высоком уровне и откладывает создание QAST на более позднее время, возможно гораздо более чистое решение проблемы анализа приемника. ... Я оптимистично уверен, что созданная мной модель будет достаточно гибкой, чтобы справиться со всеми требованиями, связанными с опусканием.

2 ElizabethMattijsen Aug 20 2020 at 21:10

Я еще не уверен, что происходит, но удаление returnоператора заставляет клонированный объект вызывать правильный sinkметод.