New Issue: Should we rename isFloatType (and friends) to something else?

19362, "stonea", "Should we rename isFloatType (and friends) to something else?", "2022-03-04T22:08:23Z"

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

In Chapel we have the following query functions that ask something about a kind of a type:

  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

Where each kind is defined as being one of the more specific types on the right hand side of this table:

  Primitives: nothing, void, bool, <anything numeric>, string, bytes
  Numeric:    <anything integral>, <anything float>, complex
  Integral:   int, uint
  Float:      real, imaginary
  Enum:       enum

For the most part I think the categories\names are good. The one that sticks out to me is 'float'. As a C programmer I'm used thinking of float as being a concrete (not a generic) type so I'm afraid some people might find this confusing.

During the module review meeting we discussed renaming this to 'isRealType' or 'isFloatingPointType' but didn't reach any consensus at the time.