Uniform handling of supported vs. unsupported operations on domains

[vasslitvinov]

This issue requests an approach or approaches for error reporting that result in helpful user error messages and are easy for domain developers to follow. it talks about domains, however it likely applies to other data types as well.

Chapel defines a number of operations on domains. Only a handful of them can be invoked on any domain, such as rank and idxType. Most of those operations are restricted in several ways:

• An operation applies only to certain domain flavors, i.e., only to one or two out of {rectangular, associative, sparse}.

• An operation on two domains is available only to certain combinations of domain flavors, ex. only to (rectangular,rectangular).

• An operation on two domains is available only when certain properties of the two domains match, ex. rank and/or idxType.

• An operation is available only to certain types of non-domain arguments. For example, domain.contains() accepts only the following sets of non-domain actual arguments:

  • N arguments of the domain's idxType where N is the domain's rank
  • a rank-tuple of values of idxType

Also (aside?): some operations are performed as promotions over one or two of its arguments, possibly domains. For example: (associative domain) += (another domain).

These restrictions are currently enforced in a variety of ways:

• A domain method has unrestricted-generic formal(s) and validity checking is done within the method. This often leads to reasonable error messages.

• A domain method overload has formals of acceptable types. The compiler issues an "unresolved call" error when the actuals are of incorrect types. Such error message comes with some detailed information, which may or may not help understand what in the user code needs to be corrected.

• One domain method overload has formals of acceptable types. Another overload has unrestricted formals and emits an error, which is likely helpful.

  This approach is less successful in distinguishing the case where the non-domain actual(s) are invalid from the case where the domain flavor is not suitable for this operation.

• There is a "last resort" overload that catches any cases that are not otherwise handled.

  This approach is also less successful in distinguishing invalid non-domain actuals from unsuitable domain flavors -- in the cases where the "payload" overloads have formals of acceptable types.

When the domain method invokes a dsiXXX method on the _value class to implement the operation, additional variations are used:

• The domain method accepts any formals, the dsiXXX() overloads perform error checking using the above strategy(ies).

• There is a dsiXXX() overload defined on BaseDom or on BaseRectangularDom / BaseAssociativeDom / BaseSparseDom that reports an error "this operations is not implemented for this domain type". This error can be reported using compilerError() or at runtime using halt() or similar.

Which of these approaches are "the best practices" and which we should proactively replace in our module code?

[vasslitvinov]

19070 improved the uniformity of user-facing errors.

Whereas this issue is about the structure of the implementation.