New Issue: should use someEnum create a shadow scope?

Notifications Issues
1

19367, "mppf", "should use someEnum create a shadow scope?", "2022-03-07T19:15:04Z"

This is a spin-off from the design proposal in #19306 and in particular [design] proposal to simplify use/import shadowing by mppf · Pull Request #19306 · chapel-lang/chapel · GitHub .

Today, one can have use someEnum bring in the enum symbols for unqualified access.

In other words, if we have

enum someEnum { a, b, c };

Then we can write e.g. someEnum.a to access the enum constants.

But, if that is not desired, one can opt in to being able to write the constants directly (with unqualified access):

enum someEnum { a, b, c };
use someEnum;
... a ...; // now refers directly to someEnum.a

Historically, use someEnum has created a shadow scope. One result of that is that with other changes in proposed in #19306, using an enum containing e leads to a multiply defined symbol error with Math.e which is included automatically.

One way to solve that specific problem is to have the implicit modules be included in a further shadow scope (see #19312).

Another way to solve the problem is for use someEnum to not introduce a shadow scope at all. Pros/Cons:

Pros (note some of this is pasted from [design] proposal to simplify use/import shadowing by mppf · Pull Request #19306 · chapel-lang/chapel · GitHub ):

  • one might think of use someEnum as "let me just bypass the fully-qualified naming" rather than "please insert shadow scopes so that I can refer to these symbols."
  • if there is a variable sharing the same name as an enum element (e.g. enum someEnum { a, b, c }; use someEnum; var a: int; ), it seems better to have an ambiguity error rather than having the local variable win

Cons (note some is pasted from [design] proposal to simplify use/import shadowing by mppf · Pull Request #19306 · chapel-lang/chapel · GitHub ):

  • use behavior is even more subtle. Now in addition to having to think about whether the use is public or private when determining how it interacts with symbols in the same scope, you additionally have to think about whether the symbol being used is a module or an enum. Are we substituting current confusion for new confusion?