New Issue: Should we have: isXType, isXValue, and isX functions for all types or just have one of these for every X?

Notifications Issues
1

19361, "stonea", "Should we have: isXType, isXValue, and isX functions for all types or just have one of these for every X?", "2022-03-04T22:02:14Z"

This is something that came up during the types module review (https://github.com/Cray/chapel-private/issues/3034)

In our types module we have documented "three flavors" of several type\value query functions:

  proc isNothingType(type t) param      proc isNothingValue(e) param      proc isNothing(e) param
  proc isBoolType(type t) param         proc isBoolValue(e) param         proc isBool(e) param
  proc isIntType(type t) param          proc isIntValue(e) param          proc isInt(e) param
  proc isUintType(type t) param         proc isUint(e) param              proc isUintValue(e) param
  proc isRealType(type t) param         proc isRealValue(e) param         proc isReal(e) param
  proc isImagType(type t) param         proc isImagValue(e) param         proc isImag(e) param
  proc isComplexType(type t) param      proc isComplexValue(e) param      proc isComplex(e) param
  proc isStringType(type t) param       proc isStringValue(e) param       proc isString(e) param
  proc isBytesType(type t) param        proc isBytesValue(e) param        proc isBytes(e) param
  proc isEnumType(type t) param         proc isEnumValue(e) param         proc isEnum(e) param

  proc isPrimitiveType(type t) param    proc isPrimitiveValue(e) param    proc isPrimitive(e) param
  proc isNumericType(type t) param      proc isNumericValue(e) param      proc isNumeric(e) param
  proc isIntegralType(type t) param     proc isIntegralValue(e) param     proc isIntegral(e) param
  proc isFloatType(type t) param        proc isFloatValue(e) param        proc isFloat(e) param

The first set of functions deal with individual types themselves, second set deal with kinds of types,

For other functions we only provide one generic type:

  proc isClass(e) param
  proc isRecord(e) param
  proc isUnion(e) param
  proc isTuple(e) param
  proc isRange(e) param
  proc isDomain(e) param
  proc isArray(e) param
  proc isDmap(e) param
  proc isSync(e) param
  proc isSingle(e) param
  proc isAtomic(e) param

In practice we also have the other two "flavors" of functions for these queries as well (we just nodoc them).

We also have proc isVoidType(type t) param, there is no such thing as a void value so it makes sense that we don't have that function (although maybe it would be better to just have 'isVoid').

Anyway, maybe it would be better if we had more consistency and either had isXType, isXValue, and isX functions for all types or just had one of these queries for all types.

During the types module review meeting people seemed to think this would be a good idea to have consistency but there wasn't agreement on what that consistency should be. We ran a stroll poll asking what people thought, these were the results:

Should we keep all three "flavors" if functions or just keep one of the flavors:

Votes: Option:
* 5    all three
* 5    isX query only
* 0    isXType query only
* 3    isXValue query only