Needs a @dsyme review since I don't have context on this omission

This is by design, though I don't feel strongly about it - the rationale is

1. if you really want a numeric type you should use UInt16.

2. The One on char is only supported to allow addition in the range operator for x in 'a' .. 'z' do ...

Is there an example which shows the good reason to support Zero on Char?

See also ConstraintSolver.fs, which would also need updating, and we would need testing of course.

      // We pretend for uniformity that the numeric types have a static property called Zero and One 
      // As with constants, only zero is polymorphic in its units
      | [], [ty], false, "get_Zero", [] 
          when IsNumericType g ty -> 
          do! SolveTypeEqualsTypeKeepAbbrevs csenv ndeep m2 trace rty ty
          return TTraitBuiltIn

      | [], [ty], false, "get_One", [] 
          when IsNumericType g ty || isCharTy g ty -> 
          do! SolveDimensionlessNumericType csenv ndeep m2 trace ty 
          do! SolveTypeEqualsTypeKeepAbbrevs csenv ndeep m2 trace rty ty
          return TTraitBuiltIn

It's mostly for consistency. It is weird to have GenericOne supported but not GenericZero since char does have a zero value.

It's mostly for consistency. It is weird to have GenericOne supported but not GenericZero since char does have a zero value.

Can you add the fix to ConstraintSolver.fs too, and also add test cases? Thanks

@Happypig375 thank you for this contribution.

Kevin