[design] `.indices` queries on arrays => local representation of indices

Users
1

Hi Chapel Community —

A recent trend for indexable types in Chapel has been for them to support a .indices query which returns all of the indices supported by that type in a closed form. For example, tuples, strings/bytes, and lists all support .indices queries that tend to return 0..<size.

For a few releases now, arrays have also supported a .indices query, which has been a synonym for the long-term .domain query that they've supported (since an array's indices are represented by its domain). Originally, it was thought that maybe this would be an opportunity to remove support for the .domain query on arrays, unifying it with other indexable types, but that proposal wasn't very popular. As a result, we have had two synonyms for saying the same thing (Arr.domain and Arr.indices), which is something we typically try to avoid.

A recent revised proposal is to have .indices return a local representation of the array's indices rather than its domain. For example, for a distributed array Arr, Arr.domain would return Arr's distributed domain, while Arr.indices would return a normal / local domain representing its (global) indices. This proposal has been received much more positively, and would eliminate the redundancy between A.indices and A.domain that we have today.

Here, I'm asking whether anyone has any significant concerns about this direction. If so, please let me know by commenting on issue 17883, replying in this thread, or letting me know via direct message.

Thanks,
-Brad

2

Hi Chapel User Community —

Following up on this query from August, in Chapel 1.25, we did end up implementing .indices queries on arrays to give the user a local representation of the array's indices, as proposed. At present, the approach taken is as follows:

  • for array types that can represent their indices in O(1) space—essentially dense, rectangular arrays—the indices are returned as a local domain.
  • for arrays that can't—associative or sparse domains—the .indices query is an iterator that yields the indices back so that the implementation doesn't have to allocate O(n) storage for the indices (but the user can still choose to do so by storing the result of the call into a variable or another domain).

If this design causes you concern, please comment on the following issue, which describes the options available in more detail: When should `.indices` be a procedure vs. iterator? · Issue #18353 · chapel-lang/chapel · GitHub

If you're supportive of the status quo, you can give the issue a thumbs-up.

Thanks,
-Brad