It's possible that we could do the following:
1) All subs (and methods) are considered multi 'under-the-hood'.
2) If the first declaration is explicitly 'multi', then you (or
others) can provide additional overloads (using 'multi') that won't
trigger warnings.
3) If the first declaration /doesn't/ use 'multi', then defining
another sub/method of the same name triggers an error/warning. BUT,
later declarations can override this by using some sort of special
declaration.
e.g.
sub foo(Int $x) { ... }
sub foo(Str $x) { ... } # error/warning
multi sub foo(Int $x) { ... }
multi sub foo(Str $x) { ... } # ok
sub foo(Int $x) { ... }
sub foo(Str $x) is overload { ... } # ok; not sure about the trait name
This provides uniqueness checking for SMD subs by default, while still
allowing hardcore hackers to overload other people's subroutines
without their explicit consent. It's not as clean as Yuval's
suggestion, but I think it might be more acceptable to folks who are
used to SMD.
Stuart
