New Issue: CG: namespace, visibility, overloading

16411, “vasslitvinov”, “CG: namespace, visibility, overloading”, “2020-09-18T01:25:44Z”

Main issue: #8629

Here are some aspects of CG (constrained generics). Some are phrased as questions, some as statements, all are up for discussion.

Does an interface name resolve like a variable name (“scopeResolve”) or more like a function name (“function resolution”)? How about implements statements? Here are some aspects of this.

Interfaces share namespace with variables, types, functions. For example, it is an error to define an interface X in the same scope as a variable or type or function named X. use M except X excludes X whether it is an interface or a variable.

See also #10802.

Suppose I define an interface X in an outer scope, a function X in an intermediate scope, and have impements X in an inner scope. Does the function shadow the interface and we get an error “X is not an interface”?

{
  interface X(type t) {...}
  {
    proc X(type t) {...)
    {
      implements X(int);  // OK or error?
    }
  }
}

How about two implements X(int), in an outer scope and an inner scope? If my call to a CG function requires implements X(int), is this an ambituity or the closer statement wins?

{
  implements X(int);
  {
    implements X(int);
    {
      ...querying implements X(int)... // OK or "ambiguous" ?
    }
  }
}

Interfaces do not support coercion. If I have implements X(real); statement, it does not fulfill the requirement implements X(int), and visa versa.