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


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.


Reply via email to