diff options
author | Paul Phillips <paulp@improving.org> | 2013-02-12 11:05:14 -0800 |
---|---|---|
committer | Paul Phillips <paulp@improving.org> | 2013-02-12 11:05:14 -0800 |
commit | c26cc531f655cfa5b27ffb8ab25adc7ffb97aa71 (patch) | |
tree | 9c3559d40b7ea6135c39085b19b6c2702e8625d2 /test/files/pos/t704.scala | |
parent | 0c59fc9a1416cf5c45699111e8857adb03f7f0d4 (diff) | |
download | scala-c26cc531f655cfa5b27ffb8ab25adc7ffb97aa71.tar.gz scala-c26cc531f655cfa5b27ffb8ab25adc7ffb97aa71.tar.bz2 scala-c26cc531f655cfa5b27ffb8ab25adc7ffb97aa71.zip |
SI-6355, weakend implementation restriction on applyDynamic.
I realized one can successfully call an overloaded applyDynamic,
under conditions such as these:
def applyDynamic[T1](m: String)(x1: T1): Any = 1
def applyDynamic[T1, T2](m: String)(x: T1, y: T2): Any = 2
def applyDynamic[T1, T2, T3](m: String)(x: T1, y: T2, z: T3): Any = 3
So I weakened the overloading restriction to allow overloading
if each method has a distinct number of type parameters. This very
likely still allows the creation of uncallable overloads, but an
overly restrictive rule is worse. If the overload cannot be called,
it will still be discovered at the call site.
Diffstat (limited to 'test/files/pos/t704.scala')
0 files changed, 0 insertions, 0 deletions