error: ambiguous call with use statement in block scope

[BryantLam]

Forked from #11262 (comment)

Why is this code ambiguous? Shouldn't it unambiguously call M.fn?

// 1.chpl
module M {
  proc fn() { writeln("M"); }
}

proc fn() { writeln("g"); }

{
  use M;
  fn();
}

9: error: ambiguous call 'fn()'
2: note: candidates are: fn()
5: note:                 fn()

chpl version 1.19.0 and
chpl version 1.20.0 pre-release (8cb22586)

[lydia-duncan]

Function calls are always resolved by checking against all versions of the function visible to the call site, no matter their distance from it. This allows us to find the right version if a more specific match was "further out", rather than immediately throwing our hands up at the first version found

[lydia-duncan]

Meta comment - should this be a stackoverflow discussion?

[BryantLam]

That makes sense to me, but wouldn't global variables be equally affected? It seems weird to allow shadowed hijacking of global variables via an unqualified access through use statements, but not let the same to happen with functions.

Edit: I guess the difference is that variables can't be overloaded like functions like you mentioned.

[lydia-duncan]

Yeah, variables can't be overloaded is basically what my answer summarizes to. In unlimited use statements (e.g. ones without except or only lists) we have to assume that you meant to bring all these symbols in so you could use them, and it seems like it would be a bit weird for use M; and use M only foo; to have different behavior when referring to foo in the scope with the use. But I'm also coming from the world where use M; is short-hand for use M only every, symbol, in, the, mod;

[bradcray]

I agree with the "functions can be overloaded and variables can't" part of this discussion.

Copying a comment over from #11262:

I don't feel confident that the current behavior here is best / ideal if users wanted to push back against them [and suggest we do something else]. For example, we could potentially amend the current rules to permit functions to shadow one another if their signatures match (by some definition of match... these ones obviously do, but decisions would need to be made about argument names, default arguments, intents and the like. Ideally these would be similar to the rules used for override methods. I'm not enough of a language expert to know whether this is established practice in other languages or whether we'd be carving out new ground here). There's been a discussion related to this on the Arkouda project recently, though I don't feel confident that I should link to it here.

[BryantLam]

Naive question. Is this code something that would be disambiguated by overload sets?

[bradcray]

I had that question too, but based on the discussion on the Arkouda issue, I'd guess not.

[mppf]

See also #19167.

I think that the example at the top of the issue is ambiguous because isMoreVisible counts each use statement the same as a block towards parent scope, in terms of distance. Since the parent scope and the use statement have the same "distance" there is ambiguity.