New Issue: Should we retire 'domain.dim(d)'?

Notifications Issues
1

17917, "vasslitvinov", "Should we retire 'domain.dim(d)'?", "2021-06-14T17:39:27Z"

The considerations in this issue are dependent on the resolution of #17916.

This issue was raised during our domain module review on 6/10.

Proposal: remove domain.dim(d). Instead, users will pick the i-th component from the tuple returned by domain.dims.

Arguments in favor of dropping dim(d) method:

  • This will reduce the number of functions in domain's public interface.

Arguments in favor of keeping dim(d):

  • If domain.dims() remains parenthesized, then picking its i-th component will require two sets of parens, which is inelegant.

  • It does not hurt anything to have domain.dim() in addition to domain.dims. If we remove it, we and users will need to change code, which is not worth it.

  • When domain.dims requires building a tuple on the fly, it does not make sense to do that just to drop all of it except for one dimension.

  • dim(d) reads nicely. Related - another singular vs. plural tension: Locales is nice when talking about the whole array; Locale[i] would be nicer when talking about a single locale. Thankfully, with dims, we can have both, unlike with the Locales array. [But don't we want to have uniformity here? -ed.]

We also had a proposal to allow paren-less vs. paren-ful overloads, ex.:

proc domain.dims return <a tuple with all dimensions>;
proc domain.dims(d) return <the range for d-th dimension>;

This has been tried before without success, so we will not go there again.