28926, "bradcray", "Represent promotions / iteratorRecords over arrays as a pseudo-array?", "2026-06-03T21:28:54Z"
Currently, when we have a promoted computation like sin(A) or A: int, we represent this as an _iteratorRecord that knows about the resulting shape/type of the expression—which is linked to the shape/domain of the promoting array.
This issue asks whether we could take this a step further and represent such expressions as an _array record in the implementation, simply one that is implemented using code rather than storage. For example, today, given sin(A), we can't really write (sin(A))[3] and index into the result, nor do other array-like operations on the expression other than iterating over it.
One of the motivators for this issue is Parallelize scans for shape-full expressions · Issue #12707 · chapel-lang/chapel · GitHub in which I was hoping to re-use the scan implementations on local and distributed arrays by re-using the existing code with the _iteratorRecord expression representing the promotion. However, this turned out not to be possible since the array-based implementations require general array operations (like indexing).
Another motivation is that if we had a routine like:
proc foo(X: [] int) { … }
and an array like:
record pair {
var x, y: int;
}
var A: [1..n] pair;
we could potentially make a call like foo(A.x) by having the promoted field access act like a pseudo-array from foo()'s perspective. And ditto for things like foo(sin(A): real).