Should we add setter/getter methods for managing IRV in sparse arrays?

[e-kayrakli]

Sparse arrays have "implicitly replicated value". Currently, it is implemented as a field irv in a base sparse array type and it is modified/accessed via proc IRV ref { return irv; }. This approach doesn't work for sparse block arrays as they consist of multiple non-distributed sparse arrays, and do not really need to manage their own "global" irv.

So, currently we do not support manipulating IRV in sparse block arrays and it came up in https://github.com/chapel-lang/chapel/issues/16889. Under that I proposed three alternative designs for solution. Copy/pasting from my comment:

---

1. Store irv in the sparse block array, check the membership on remote access in the distributed class and return the distributed array's IRV. But this would cause extra comm on remote access.
2. Store irv in the sparse block array, add a new method on sparse arrays that is similar to dsiAccess, but returns a tuple which contains the value and whether or not it is IRV. This would allow the internal non-distributed arrays to return their own IRV for non-existing index along with a flag, and the distributed array to override the IRV with its own.
3. Use setter/getter methods for managing the IRV. Sparse block array's setter can broadcast the value to the local instances. But you'd lose the ability to do mySparseArr.IRV = 5, and would need mySparseArr.setIRV(5). I think setting IRV is not a common operation and this wouldn't feel too ugly.

2 would still have some additional checks on remote access. This is probably not an issue today, but may be in the future when sparse arrays are optimized. 3 is a clean implementation with no performance issues that I can think of, but it is a breaking change (not that sparse interface is stable but still...) and requires a design discussion. 1 can be a considered as a correctness bandaid, I don't think it is what we want in the long term.

---

@bradcray is in favor of 3 among those and I agree. If we were to follow that approach, we should discuss method names. I can think of the following:

• setIRV/getIRV
• setIrv/getIrv
• setReplicatedVal/getReplicatedVal

[bradcray]

Of these options, I like setIRV / getIRV.

Or, I might only support setIRV and permit it to still be read using myArray.IRV (or both myArray.IRV and myArray.getIRV()).