I just realize one issue with user-defined operators that might not have been discussed here yet, shadowing.

If an operator is defined in outer and inner scopes, say with different enough argument types, is the outer one still accessible in the inner scope (i.e., the inner one overloads the outer one) (a), or not accessible (i.e., shadows) (b)?

If (a), what if argument types are similar enough? Will usual ambiguity resolution (or complaining) rules apply (c), or will the inner operator be stronger (d)?

If (b), what about built-in operators? If something like + is overloaded with new argument types, the built-in + is still available (e). But if it's overloaded again in an inner scope, and the outer operator is shadowed, does the built-in operator remain unshadowed (f) or not (g).

Of course, the same questions can be asked about function overloading as well.

(c) that's basically what GPC currently does (where ambiguity resolution rules are name-based and first-match, which is bad, as was said before)

(d) this might be more logical, as the relationship between inner and outer operators would be the same as between outer and built-in ones -- the latter come into play only if the former have no possible match at all

(e) that's so in GPC currently, but I suppose also elsewhere, isn't it? I.e., defining one + operator doesn't shadow the built-in +.

(f) if the outer operator shadows the built-in operator (by using similar argument types, say operator + (a, b: Integer) -- if this will be allowed at all), and the inner operator has completely different types, the built-in + for Integer would "reemerge" in the inner scope, very strange

(g) one user-defined operator does not shadow a built-in, but two nested ones do -- also strange

What do other dialects do about it?

Frank