Kris wrote:
> In article <cvnt5c$1bre$1@digitaldaemon.com>, Ben Hinkle says...
> 
>>
>>"Kris" <Kris_member@pathlink.com> wrote in message 
>>
>>>Bork. The number of errors is dependent upon order of foo() declarations.
>>
>>Hmm. The error message I got (and I just tried with the reposted example) is just the multiple match error. 
> 
> 
> That's due to the order of foo() declarations, as noted above. Switch them
> around (or change x from uint to int; or vice versa) and you'll get the
> "cast(type)(x) not an lvalue" as well.
> 

Here's what I'm getting on Windows with DMD 0.113:

In this order:
void foo (inout int x, uint y = 10){}
void foo (inout uint x, uint y = 10){}
I get:
bork.d(10): function bork.foo overloads void(inout uint x,uint y = cast(uint)(10)) and void(inout int x,uint y = cast(uint)(10)) both match argument list for foo

In this order:
void foo (inout uint x, uint y = 10){}
void foo (inout int x, uint y = 10){}
I get:
bork.d(10): function bork.foo overloads void(inout uint x,uint y = cast(uint)(10)) and void(inout int x,uint y = cast(uint)(10)) both match argument list for foo
bork.d(10): cast(uint)(x) is not an lvalue

I both cases I get the multiple overloads error, and in one I also get the strange "not an lvalue".

I agree, this is strange. Both of the errors, in fact.  Although, I have noticed that DMD tends to give a lot of cryptic/inaccurate error messages anyway - I've just been attributing it to DMD still being beta. Perahps this is just due to some underlying bug in default arguments?

Just to clarify, are you saying you think something about the method resolution needs redesigned, or that it just needs a lot of bug-fixing?

Nick Sabalausky wrote:
> Kris wrote:
> 
>> In article <cvnt5c$1bre$1@digitaldaemon.com>, Ben Hinkle says...
>>
>>>
>>> "Kris" <Kris_member@pathlink.com> wrote in message
>>>
>>>> Bork. The number of errors is dependent upon order of foo() declarations.
>>>
>>>
>>> Hmm. The error message I got (and I just tried with the reposted example) is just the multiple match error. 
>>
>>
>>
>> That's due to the order of foo() declarations, as noted above. Switch them
>> around (or change x from uint to int; or vice versa) and you'll get the
>> "cast(type)(x) not an lvalue" as well.
>>
> 
> Here's what I'm getting on Windows with DMD 0.113:
> 
> In this order:
> void foo (inout int x, uint y = 10){}
> void foo (inout uint x, uint y = 10){}
> I get:
> bork.d(10): function bork.foo overloads void(inout uint x,uint y = cast(uint)(10)) and void(inout int x,uint y = cast(uint)(10)) both match argument list for foo
> 
> In this order:
> void foo (inout uint x, uint y = 10){}
> void foo (inout int x, uint y = 10){}
> I get:
> bork.d(10): function bork.foo overloads void(inout uint x,uint y = cast(uint)(10)) and void(inout int x,uint y = cast(uint)(10)) both match argument list for foo
> bork.d(10): cast(uint)(x) is not an lvalue
> 
> I both cases I get the multiple overloads error, and in one I also get the strange "not an lvalue".
> 
> I agree, this is strange. Both of the errors, in fact.  Although, I have noticed that DMD tends to give a lot of cryptic/inaccurate error messages anyway - I've just been attributing it to DMD still being beta. Perahps this is just due to some underlying bug in default arguments?
> 
> Just to clarify, are you saying you think something about the method resolution needs redesigned, or that it just needs a lot of bug-fixing?

Before realizing the default-arg was involved in some bizarre manner, I put this down to another glorious wart in that area of the language; hence the thread title. As it turns out, it appears to be an unintentional mistake that will hopefully (one would imagine) be resolved quickly.

As to my thoughts about some of the related design aspects: you'll forgive me if I refrain from opening that particular Pandora's Box ~ we've been down that path before, and I'm not writing the compiler.

Cheers;

Kris <Kris_member@pathlink.com> wrote:

[...]
> 
> void foo (inout int x, uint y = 10){}
> void foo (inout uint x, uint y = 10){}
> 
> void bar()
> {
> int x;
> 
> foo (x);     // good
> 
> foo (x, 0);  // fails, with error on type of 'x', and multiple
> sig match }
> 
> As you can see, there's no possible confusion over the type of 'y' -- they're both of type 'uint'. Yet the complier error points at a problem with 'x'. Bork. Bork. The number of errors is dependent upon order of foo() declarations.
> 
> I'm a bit surprised no-one else seems to have posted about this in the past.

That is no surprise: the error messages are totally okay, because there is no exact match and no single match by implicit casting and/or integer propagation. Therefore the multiple signature match is okay. And if there are multiple signature matches then the lexically first is choosen for exact comparison of the elements of the signature, giving one more error in the case that the (uint, uint)- version comes lexically first.

-manfred

In article <cvqfcj$11bl$1@digitaldaemon.com>, Manfred Nowak says...
>
>Kris <Kris_member@pathlink.com> wrote:
>
>[...]
>> 
>> void foo (inout int x, uint y = 10){}
>> void foo (inout uint x, uint y = 10){}
>> 
>> void bar()
>> {
>> int x;
>> 
>> foo (x);     // good
>> 
>> foo (x, 0);  // fails, with error on type of 'x', and multiple
>> sig match }
>> 
>> As you can see, there's no possible confusion over the type of 'y' -- they're both of type 'uint'. Yet the complier error points at a problem with 'x'. Bork. Bork. The number of errors is dependent upon order of foo() declarations.
>> 
>> I'm a bit surprised no-one else seems to have posted about this in the past.
>
>That is no surprise: the error messages are totally okay, because there is no exact match and no single match by implicit casting and/or integer propagation. Therefore the multiple signature match is okay. And if there are multiple signature matches then the lexically first is choosen for exact comparison of the elements of the signature, giving one more error in the case that the (uint, uint)- version comes lexically first.

--------------------

[Ignoring the bogus msg about cast(uint)(x)]

Aye;  that's logically sound ~ if you're behind the looking-glass. Just part of the twisted horror foisted upon us through the combination of method-overloading and implicit-casting.

Are you perhaps saying this is a /good/ thing, Manfred ?


WALTER:  Follow!  But! follow only if ye be men of valor, for the entrance
to this cave is guarded by a notion so foul, so cruel, that no man
yet has fought with it and lived!  Bones of four fifty men lie strewn
about its lair. So, brave knights, if you do doubt your courage or
your strength, come nae further, for death awaits you all with nasty,
big, pointy teeth ...


[The rest of us; chanting]
Pie Iesu domine, dona eis requiem.
[bonk]
Pie Iesu domine,...
[bonk]
..dona eis requiem.
[bonk]
Pie Iesu domine,...
[bonk]
..dona eis requiem.

Kris <Kris_member@pathlink.com> wrote:

[...]
> Are you perhaps saying this is a /good/ thing, Manfred ?

Good or bad is decided on ones wishes.

It is known that every error renders the following code more or less useless. Therefore the error messages generated after the first error message are also more or less useless.

In this case the first error message reported is that of a multiple signature match.

If you are content with this, then just ignore the following error messages gegenrated by the compiler.

If you want more information than that first error message, please generically describe what you want.

Walter has choosen the solution with the least computational complexity for the compiler but one of the main goals of D is to increase productivity.

So, instead of intoning choruses prove that your wish improves productivity in general and Walter will follow.

-manfred

"Nick Sabalausky" <a@a.a> wrote in message news:cvp5q6$2ivf$1@digitaldaemon.com...
> Kris wrote:
> > In article <cvnt5c$1bre$1@digitaldaemon.com>, Ben Hinkle says...
> >
> >>
> >>"Kris" <Kris_member@pathlink.com> wrote in message
> >>
> >>>Bork. The number of errors is dependent upon order of foo()
declarations.
> >>
> >>Hmm. The error message I got (and I just tried with the reposted
example) is
> >>just the multiple match error.
> >
> >
> > That's due to the order of foo() declarations, as noted above. Switch
them
> > around (or change x from uint to int; or vice versa) and you'll get the
> > "cast(type)(x) not an lvalue" as well.
> >
>
> Here's what I'm getting on Windows with DMD 0.113:
>
> In this order:
> void foo (inout int x, uint y = 10){}
> void foo (inout uint x, uint y = 10){}
> I get:
> bork.d(10): function bork.foo overloads void(inout uint x,uint y =
> cast(uint)(10)) and void(inout int x,uint y = cast(uint)(10)) both match
> argument list for foo
>
> In this order:
> void foo (inout uint x, uint y = 10){}
> void foo (inout int x, uint y = 10){}
> I get:
> bork.d(10): function bork.foo overloads void(inout uint x,uint y =
> cast(uint)(10)) and void(inout int x,uint y = cast(uint)(10)) both match
> argument list for foo
> bork.d(10): cast(uint)(x) is not an lvalue
>
> I both cases I get the multiple overloads error, and in one I also get the strange "not an lvalue".

What happens is there's an overload error where two functions match the argument list types. So the compiler reports the first error message. Then, it attempts to recover from the error by just picking one of the functions (the first one) and soldiering on, trying to make it work. This results in the second error message when that doesn't work.

> I agree, this is strange. Both of the errors, in fact.

Why is the first error message strange?

"Manfred Nowak" <svv1999@hotmail.com> wrote in message news:cvs3dl$2km0$1@digitaldaemon.com...
> Walter has choosen the solution with the least computational complexity for the compiler but one of the main goals of D is to increase productivity.

I find C++ overloading rules to be exceptionally and overly complicated, with layers and layers of special cases and rules only an expert would understand. For D I opted for a simple 3 level matching system - exact match, match with implicit conversions, no match. So, for the example, comparing the types of the arguments with the types for each of the function, each function is matched with implicit conversions, hence the ambiguity error:

    foo(int, uint)
    foo(uint, uint)

called with two int arguments, c and 12, looking like:

    foo(int, int)

The rule is easy to explain. I think much of the confusion comes from being used to the complicated C++ rules, that when it's so simple, I suspect people just assume it is far more complicated than it is.

I think this can be cleared up by improving the error message.

On Sun, 27 Feb 2005 10:31:34 -0800, Walter wrote:

[snip]

> I think this can be cleared up by improving the error message.

Agreed. A simple message such as "cannot find a matching routine for foo(int,int)" would be wonderful.

My main issue is that the current message does not make it clear what are the results of implicit conversions. Especially with literals.
-- 
Derek
Melbourne, Australia

In article <cvs3dl$2km0$1@digitaldaemon.com>, Manfred Nowak says...
>
>So, instead of intoning choruses prove that your wish improves productivity in general and Walter will follow.


That's a convenient, if disingenuous position to take. You might as well suggest this instead: "prove Iraq had no weapons-of-mass-destruction, and Bush will step down from office".

Whatever one's personal beliefs are, neither will happen ~ so let's forego the "Norman Rockwell", please.

If you feel that such behaviour (the topic) is indicative of a language that will be a wild and raving success, then fair enough. I think it could be handled a whole lot more intuitively ~ and I'm bringing it up, based on real-world experience with D, so that it doesn't get swept under the carpet.

"Derek" <derek@psych.ward> wrote in message news:1h5dxczfxlo28$.1l3a1aduh16x5.dlg@40tude.net...
> On Sun, 27 Feb 2005 10:31:34 -0800, Walter wrote:
> > I think this can be cleared up by improving the error message.
>
> Agreed. A simple message such as "cannot find a matching routine for foo(int,int)" would be wonderful.
>
> My main issue is that the current message does not make it clear what are the results of implicit conversions. Especially with literals.

I've modified the error message to be:

C:mars>dmd test
test.d(9): function test.foo called with argument types:
        (char[],int,int)
matches both:
        test.foo(char[],int,uint)
and:
        test.foo(char[],uint,uint)

This will go out in the next update.