- About Scala
- Documentation
- Code Examples
- Software
- Scala Developers
Why is the compiler complaining about default argument values?
Wed, 2012-02-01, 02:04
In a class, the following three method signatures are defined:
def insert(at: Int, insertee: Mark, direction: Direction = Forward): Mark = ... def insert(at: Mark, insertee: Mark, direction: Direction = Forward): Mark = ...
def insert(at: Mark, content: Content, direction: Direction);
The types of arguments ensure that there can be no possible ambiguity as to which is called (there is no inheritance between Content and Mark). However, the compiler says:
error: in trait Element, multiple overloaded alternatives of method insert define default arguments.trait Element {
Why is this a problem? There's no erasure happening, so I don't see why there would be any run-time ambiguity.
Thanks,Ken
def insert(at: Int, insertee: Mark, direction: Direction = Forward): Mark = ... def insert(at: Mark, insertee: Mark, direction: Direction = Forward): Mark = ...
def insert(at: Mark, content: Content, direction: Direction);
The types of arguments ensure that there can be no possible ambiguity as to which is called (there is no inheritance between Content and Mark). However, the compiler says:
error: in trait Element, multiple overloaded alternatives of method insert define default arguments.trait Element {
Why is this a problem? There's no erasure happening, so I don't see why there would be any run-time ambiguity.
Thanks,Ken
Wed, 2012-02-01, 14:21
#2
Re: Why is the compiler complaining about default argument valu
Note that the original version of the code allowed multiple overloads
with default arguments. It was then changed to the single overload
restriction based on the experience with the former.
On Tue, Jan 31, 2012 at 23:08, Sciss wrote:
> unfortunately you cannot mix overloading and default arguments... (well, you can have _one_ method with defaults, but not more than one). this was done for simplicity, even if it would be possible to allow both overloading and multiple default arguments.
>
> http://stackoverflow.com/questions/4652095/why-does-the-scala-compiler-d...
>
> best, -sciss-
>
>
> On 1 Feb 2012, at 01:04, Ken McDonald wrote:
>
>> In a class, the following three method signatures are defined:
>>
>> def insert(at: Int, insertee: Mark, direction: Direction = Forward): Mark = ...
>> def insert(at: Mark, insertee: Mark, direction: Direction = Forward): Mark = ...
>> def insert(at: Mark, content: Content, direction: Direction);
>>
>> The types of arguments ensure that there can be no possible ambiguity as to which is called (there is no inheritance between Content and Mark). However, the compiler says:
>>
>> error: in trait Element, multiple overloaded alternatives of method insert define default arguments.
>> trait Element {
>>
>> Why is this a problem? There's no erasure happening, so I don't see why there would be any run-time ambiguity.
>>
>> Thanks,
>> Ken
>
Wed, 2012-02-01, 20:11
#3
Re: Why is the compiler complaining about default argument valu
Hmm, interesting. Good to know, at least.
Ken
Ken
unfortunately you cannot mix overloading and default arguments... (well, you can have _one_ method with defaults, but not more than one). this was done for simplicity, even if it would be possible to allow both overloading and multiple default arguments.
http://stackoverflow.com/questions/4652095/why-does-the-scala-compiler-d...
best, -sciss-
On 1 Feb 2012, at 01:04, Ken McDonald wrote:
> In a class, the following three method signatures are defined:
>
> def insert(at: Int, insertee: Mark, direction: Direction = Forward): Mark = ...
> def insert(at: Mark, insertee: Mark, direction: Direction = Forward): Mark = ...
> def insert(at: Mark, content: Content, direction: Direction);
>
> The types of arguments ensure that there can be no possible ambiguity as to which is called (there is no inheritance between Content and Mark). However, the compiler says:
>
> error: in trait Element, multiple overloaded alternatives of method insert define default arguments.
> trait Element {
>
> Why is this a problem? There's no erasure happening, so I don't see why there would be any run-time ambiguity.
>
> Thanks,
> Ken