openlang

Один и тот же вызов с sink, сначала копия, потом перенос

Nim 2 решает, копировать или переносить, в каждой точке вызова. Не на уровне proc.

proc take(s: sink seq[int]) =
  echo s.len

proc main() =
  var a = @[1, 2, 3]
  take(a)  # copied, `a` is read again below
  take(a)  # last read of `a`, moved

main()

Тот же аргумент, та же proc. Первый вызов копирует, потому что a ещё нужна. Второй переносит. В точке вызова не видно, что именно произойдёт. nim c --expandArc:main печатает переписанное тело, там видно оба случая.

Только локальные переменные. В документации по деструкторам сказано, что анализ ограничен локальными переменными, поэтому проверка живёт в proc, а --expandArc всё равно принимает её имя.

Разговор продолжается 2

Следуя доводам
  1. Ссылка на ответ

    sink - забавное слово для этого. Вслух звучит так, будто вызываемая сторона обещает проглотить значение. На деле обещание скромнее. Вызываемая сторона может оставить значение себе, а если не оставит, оно уничтожается в конце вызываемой процедуры, а не у вызывающего. Так что честное прочтение - "может забрать", и вызывающий по самому вызову всё равно не поймёт, заплатил ли он за копию.

    А --expandArc как-то сообщает о копии, или каждый раз надо читать вывод глазами?

Другие стороны того же вопроса

  1. Предупреждение про висячий указатель пропало, а указатель остался

    Передаю имя в библиотеку на C++ через обёртку, и сначала написал всё в одну строку, CString::new(name).unwrap().as_ptr(), и r…

    Ответы 1rustcpp
  2. getline оставляет буфер вызывающему, даже когда возвращает -1

    POSIX getline выделяет или увеличивает буфер через переданный указатель, и этот буфер принадлежит вызывающему с первого же вы…

    Ответы 4c
  3. Ссылка на интерфейс и ссылка на объект для одного экземпляра

    Ошибка времени жизни, которую я чаще всего встречаю в старом коде на Delphi, возникает, когда на одном экземпляре смешивают д…

    Ответы 5object-pascal