should it be possible to shadow a symbol brought in with import?

[mppf]

In https://chapel-lang.org/docs/language/spec/procedures.html#determining-more-specific-functions it says that X is more specific than Y if X shadows Y.

I can understand why "shadowing" should be allowed for a use statement but it is not so clear to me that we should allow it for the corresponding example with import.

Here is an example with a function:

module M {
  import N.f;

  proc f() {
    writeln("M.f");
  }

  proc main() {
    f();
  }
}

module N {
  proc f() {
    writeln("N.f");
  }
}

This compiles today and prints M.f. I think it should not compile, because I think of import as creating a local symbol just like the proc declaration does.

Here is a similar example for scope resolution:

module M {
  import N.x;

  var x = "M";

  proc main() {
    writeln(x);
  }
}

module N {
  var x = "N";
  proc f() {
    writeln("N.f");
  }
}

Which also compiles and prints M.

Both of the above examples currently behave the same with public import.

[mppf]

@lydia-duncan tells me that it is this way intentionally and that the rationale can be summarized as keeping import as consistent with use as possible (but with different default behavior).

[bradcray]

I feel like I could live with either the current behavior or the proposed behavior here as long as we're only talking about imports and symbol definitions at the same scope and not cases where they're at staggered scopes like:

import M.x;
{
  var x = ...;
  ...x...  // local var x should win here
}

Even if we didn't go so far as making the cases in the OP an error, I think it could merit a warning since it seems that something is wrong in the code (either you didn't need to import it or you didn't mean to shadow it).

Your examples also have the property that the function signatures are identical, but for the paren-ful subroutine case presumably I could add local overloads of a function using a different signature and call either version as appropriate (i.e., it would add to the overload set rather than eclipsing the imported version(s) of the procedure).

[mppf]

I feel like I could live with either the current behavior or the proposed behavior here as long as we're only talking about imports and symbol definitions at the same scope and not cases where they're at staggered scopes like

Yes, and I agree. It seemed odd to me at first but I'm not convinced we need to change it, either.

Your examples also have the property that the function signatures are identical, but for the paren-ful subroutine case presumably I could add local overloads of a function using a different signature and call either version as appropriate (i.e., it would add to the overload set rather than eclipsing the imported version(s) of the procedure).

Yes

[skaller]

See #19167

[mppf]

In particular the relevant part is

So now for the second issue. When you import modules into another exclusively for the implementation of that module and not for re-exportation, you need to be able to resolve conflicts, but only inside that module.

which is saying that the ability to shadow a symbol brought in with import can be useful when using shadowing to resolve conflicts.

I think the counter-argument to that is that you can just rename it when you import it e.g. import C as A;

[mppf]

It occurred to me to think about how public import would impact the situation.

From the last paragraph in https://chapel-lang.org/docs/language/spec/modules.html#conflicts :

Symbols brought in directly by a public import are treated as though defined at the scope with the public import for the purpose of determining conflicts (see Re-exporting). This means that if the public use in module B of the previous example was instead replaced with a public import A.x, A’s x would conflict with C.x when resolving the main function’s body.

But, both of the examples in the original post behave the same with public import (shadowing and ending up working with the symbol in M).

So for public import it is not behaving as specified, at least.

And then, supposing we fixed public import, then I think I would not want toggling public/private on the import to change the behavior of these programs, and so I would argue that it shouldn't be possible to shadow in this way, and the conflict should be reported immediately.

[mppf]

Correcting something from #19160 (comment)

The spec does indicate that public import introduces a shadow scope -- https://chapel-lang.org/docs/language/spec/modules.html#re-exporting

Making a use or import public causes the symbols brought in by that statement to be visible as though they were defined in the scope with the use or import, a strategy which will be referred to as re-exporting. However, symbols with the same name in the scope with the use or import will still take precedence.

The earlier paragraph gave the impression it did not have a shadow scope but linked here.

[bradcray]

@mppf: After #19306 this seems to be working in a much more satisfying way. What more needs to be done to resolve this?

[mppf]

Yes, #19306 makes the import no longer introduce a shadow scope. To make sure we didn't lose the test case in the OP, I've created #19798 to add two variations it (and to note in a comment two other tests are related to this issue). Closing this issue.