New Issue: Should errors in function signatures cause errors or failure to find a candidate?

Notifications Issues
1

17172, "mppf", "Should errors in function signatures cause errors or failure to find a candidate?", "2021-02-16T16:17:57Z"

Suppose we have some overloaded functions along these lines:

proc f(firstArg, secondArg: computeType(firstArg)) {
  writeln("f - computeType");
}
proc f(firstArg, secondArg) {
  writeln("f - generic");
}

Here I mean for computeType to stand in for any sort of type construction expression (along the lines of R(int) or owned MyClass).

What happens if we call f for a type where computeType is not available?

f(1, 1);

Today we get a compilation error along these lines:

example.chpl:1: In function 'f':
example.chpl:1: error: unresolved call 'computeType(int(64))'
example.chpl:1: note: because no functions named computeType found in scope
  example.chpl:1: called as f(firstArg: int(64), secondArg: _unknown)
note: generic instantiations are underlined in the above callstack

Should this be an error? Or, should the f with a computeType type expression just not be a candidate (resulting in the program compiling and outputting f - generic at runtime).

A related concept from C++ is Substitution Failure is not an Error (SFINAE).

I ran into this problem when converting casts to operators for PR #17146. The natural order of arguments for the operator cast is that the LHS is the value and the RHS is the type casted to.

I converted:

  proc _cast(type t:AtomicT(?T), rhs: T)

into

  operator :(rhs: ?T, type t:AtomicT(T) )

which caused type construction for many more types when computing candidates for : calls and the type construction for e.g. Atomic(c_void_ptr) resulted in compilation errors.