Behavior difference between returning and yielding tuples with maps

[e-kayrakli]

Consider the analogous pair of iterator and subroutine foo and bar.

use Map;

iter foo() { // need `ref` return intent to compile
  var m = new map(string, int);
  yield (m, 5);
}
var Arr = for item in foo() do item;
writeln(Arr);

// the following works:
proc bar() {
  var m = new map(string, int);
  return (m, 5);
}

var x = bar();
writeln(x);

They both return a tuple of a local map and an integer. bar doesn't require a ref return intent, while foo requires it. I think this is inconsistent and should be addressed. The fact that integer is a literal doesn't change anything, it could also be a local variable.

I don't feel very confident in my understanding of the semantics here. In my real use case, I was writing the iterator, fully expecting it to create a copy of the map without too deep of a thinking. Therefore, in this case, I feel ref is redundant and that proc bar is compiled correctly where iter foo is not. There might be some subtleties requiring a ref. However, the behavior should be consistent between the proc and iter.

[e-kayrakli]

Note that #26475 makes a relevant fix. But it doesn't fix the problem here.

[vasslitvinov]

My intuition is that m should be yielded from foo by value if it is not used after the yield, otherwise by const ref. The integers in the tuple should be yielded by value. More formally, both should be yielded by const, letting the implementation choose by value or by const ref, given foo's default yield intent.

I am not sure whether this is what the spec says. The relevant pages are https://chapel-lang.org/docs/main/language/spec/iterators.html#the-yield-statement and https://chapel-lang.org/docs/main/language/spec/tuples.html#tuple-yield-behavior .

Fundamentally, we have agreed that "Tuple yield behavior matches tuple return behavior, except yielding a local tuple is allowed." with the open issue that "We also need to provide a mechanism to yield referential tuples."