summaryrefslogtreecommitdiff
path: root/test/files/neg/t6355.check
Commit message (Collapse)AuthorAgeFilesLines
* SI-6355 SI-7059 it is possible to overload applyDynamicEugene Burmako2013-12-281-7/+0
| | | | | | | As our discussion at https://issues.scala-lang.org/browse/SI-6355 shows, it looks like it is possible to overload applyDynamic, even though a straightforward way is closed. This commit codifies the pattern proposed by @paulp and makes sure that it doesn’t break in the future.
* SI-6355, weakend implementation restriction on applyDynamic.Paul Phillips2013-02-121-2/+5
| | | | | | | | | | | | | | | 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.
* Error for SI-6355, overloading of applyDynamic.Paul Phillips2012-11-141-0/+4
As long as it can never be called anyway, seems like we'd be doing people a kindness to fail the compile rather than letting it be ambiguous at every use site.