External Issue: Multiplying a tuple of reals by a scalar int fails to promote int to real

Notifications Issues
1

18104, "npadmana", "Multiplying a tuple of reals by a scalar int fails to promote int to real", "2021-07-23T00:53:06Z"

Summary of Problem

Consider the following code

var x : 3*real;
writeln(3*x);

Compiling this with Chapel 1.24.1 fails with the following error message

tuple1.chpl:2: error: unresolved call '*(3, 3*real(64))'
$CHPL_HOME/modules/internal/ChapelBase.chpl:321: note: this candidate did not match: *(a: imag(32), b: imag(32))
tuple1.chpl:2: note: because actual argument #1 with type 'int(64)'
$CHPL_HOME/modules/internal/ChapelBase.chpl:321: note: is passed to formal 'a: imag(32)'
tuple1.chpl:2: note: other candidates are:
$CHPL_HOME/modules/internal/ChapelBase.chpl:321: note:   *(a: imag(64), b: imag(64))
$CHPL_HOME/modules/internal/ChapelBase.chpl:325: note:   *(a: imag(32), b: real(32))
note: and 59 other candidates, use --print-all-candidates to see them

However, reversing the 3 and x has the code compile just fine, i.e.

var x : 3*real;
writeln(x*3);

This issue was pointed out by @ClaireRecamier on gitter.

@bradcray diagnosed the issue to be (copying the discussion from gitter) --

I think the issue is that the overload that you’d hope would fire in a case like this is this one:

  inline operator *(x: ?t, y: _tuple) where isHomogeneousTuple(y) &&
                                        isSubtype(t, (y(0).type)) {

but that the isSubtype() relationship doesn’t take coercions into account. Whereas when the scalar is on the RHS of the expression, we call this one:

  inline operator *(x: _tuple, y: x(0).type) where isHomogeneousTuple(x) {

where the second argument will be constrained to be : real which does support the coercion. I’m trying to recall whether we have another query that can be used in place of isSubtype to get the expected behavior, but the first two things I tried haven’t worked.
I think it’s definitely worth filing a feature request / bug issue against this in any case (the rationale being that we should support a given type combination commutatively in multiplications).