Walter wrote:

> For D I opted for a simple 3 level matching system - exact
> match, match with implicit conversions, no match. 

The guys forced to do C++ for a living would cry big tears of envy. ;-)

BTW, is it possible that overloading should be in that phrase somewhere?

Implicit conversion is mathcing arguments to the function at hand, and overload resolution is the opposite (i.e. matching functions to the arguments at hand). I'd sure wish for it to be as easy to remember when that happens, as it is to remember the excellent "three level rule" of D.

On Sun, 27 Feb 2005 13:44:58 -0800, Walter wrote:
> 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.

That'll do it. Thank you.

-- 
Derek
Melbourne, Australia
28/02/2005 8:57:27 AM

"Kris" <Kris_member@pathlink.com> wrote in message news:cvte46$rl4$1@digitaldaemon.com...
> 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.

Whatever your position on such matters - and beware this advice from me precisely because I agree with him about most things - I think Kris' opinions are generally well worth regarding because he is doing a lot of D. AFAIK, and please correct me if I'm wrong, Mango is the largest single D project thus far. Even if I'm wrong about that, Mango's certainly brought to the fore many previously unforeseen issues in 'normal' D.

FWIW, when I _finally_ get back to DTL next month, I expect it'll provide a similar function for the template side of D. I'm going to start by trawling the NG and various projects for template wisdoms, and then jump back in. So, any template-related issues/ideas are best floated (either here or via email) in next 2-3 weeks.

"Walter" <newshound@digitalmars.com> wrote in message news:cvtf29$sri$1@digitaldaemon.com...
>
> "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.

That'll be a big boon.

"Georg Wrede" <georg.wrede@nospam.org> wrote in message news:42224176.8020809@nospam.org...
>
>
> Walter wrote:
>
>> For D I opted for a simple 3 level matching system - exact match, match with implicit conversions, no match.
>
> The guys forced to do C++ for a living would cry big tears of envy. ;-)

<rant>
Not so. I know you've a smiley there, but I really think this "C++ is
too complicated, D is superior" is incredibly hasty, not to say naive.

I accept that from the compiler writer's perspective, D wins out over C++ in straightforwardness, implementatility, etc.etc.

But I cannot believe everyone simply takes as read that out there, in the real world of large projects and diverse and tricky minds, D can be confidently stated and assumed to be superior.

I'll give you one tiny little issue: D does not have implicit template instantiation. This has potentially enormous ramifications. It may turn out that Walter has another of his brilliant insights and works a way around it, or that we discover techniques with module namespaces and 'standard' utility function conventions that obviate it. But that's all a big maybe. To ignore/dismiss this _at this time_ is just mental.

And there are lots more. We've only scratched the surface of TMP so far. The module model is, AFAICT, still a bit confused/ing. I don't think the issue of dynamic link-units is solved to everyone's satisfaction as yet. There's an ugly amount of coupling. We are yet to see how D's 'slack' implicit conversion handles in big projects with multiple developers and commercial deadlines.

I think the writing of DPD, the maturation of D towards 1.0, and the increasing number and sophistication of libraries like Mango will, over the next several months, inform on this debate. But it is *not* a done deal at the moment, and saying so makes the D community, IMO, look somewhat idiotic.

btw, all the foregoing is not aimed at Georg personally, just at the oft espoused idea that "D's superior to C++". It's not, albiet I look forward to 2005 being the year that it achieves the status of being so, or at least being a highly attractive alternative.


</rant>

In article <cvt3m9$iao$1@digitaldaemon.com>, Walter says...
>
>
>"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.


It may, indeed, be simpler in certain manifest ways. Yet, the fact remains that implicit-casting and method-overloading make ill-suited bedfellows.

Just look at what we (the users) have to do with 'alias' to bring back superclass methods that have had their name overloaded in the subclass? Each of those contrived old examples as to /why/ alias is supposedly necessary are based upon the fragility of combined implicit-casting & overloading within various scenarios.

Here's another old & trivial example of this type of bogosity:

void print (char[] s);
void print (wchar[] s);

{print ("bork");}

Because the char literal can be implicitly cast to wchar[], the compiler fails. One has to do this instead:

print (cast(char[]) "bork");

This is daft, Walter. And it hasn't been fixed a year later.

Oh, and let's not forget that D will implicitly, and silently, convert a long argument into an int or byte. Not even a peep from the compiler. MSVC 6 certainly will not allow one to be so reckless. If I drove my car in a similar manner, I'd likely be put in jail.

There's many, many more examples. Here's another old one that I always found somewhat amusing: news:cgat6b$1424$1@digitaldaemon.com

I'm not saying that implicit-casting is necessarily bad, and I'm not saying that method-overloading is bad. I am saying the combination of the two leads to all sort of nastiness; some of which you've attempted to cover-up by implicitly hiding superclass method-names overloaded by a subclass, and which you just might cover up with an explicit-type-prefix on "literal" strings (such as w"wide-string").

It shouldn't have to be like this. Surely there's a more elegant solution all round, both for the compiler and for the user? Less special-cases is better for everyone.

- Kris

In article <cvtf29$sri$1@digitaldaemon.com>, Walter says...
>
>
>"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.


That certainly cannot make matters worse. The problem, though, is that the compiler can inadvertantly focus one in the wrong direction (in my case it was the 'inout int' and 'inout uint' that I thought was wrong). It was two days before anyone posted the real crux of the error. I think that indicates a problem that this reworked error message does not address.

Having said that, better diagnostics are always welcome.

Matthew wrote:
> "Georg Wrede" <georg.wrede@nospam.org> wrote in message news:42224176.8020809@nospam.org...
> 
>>
>>Walter wrote:
>>
>>
>>>For D I opted for a simple 3 level matching system - exact
>>>match, match with implicit conversions, no match.
>>
>>The guys forced to do C++ for a living would cry big tears of envy. ;-)
> 
> 
> <rant>
> Not so. I know you've a smiley there, but I really think this "C++ is too complicated, D is superior" is incredibly hasty, not to say naive.
> 
> I accept that from the compiler writer's perspective, D wins out over C++ in straightforwardness, implementatility, etc.etc.
> 
> But I cannot believe everyone simply takes as read that out there, in the real world of large projects and diverse and tricky minds, D can be confidently stated and assumed to be superior.
> 
> I'll give you one tiny little issue: D does not have implicit template instantiation. This has potentially enormous ramifications. It may turn out that Walter has another of his brilliant insights and works a way around it, or that we discover techniques with module namespaces and 'standard' utility function conventions that obviate it. But that's all a big maybe. To ignore/dismiss this _at this time_ is just mental.
> 
> And there are lots more. We've only scratched the surface of TMP so far. The module model is, AFAICT, still a bit confused/ing. I don't think the issue of dynamic link-units is solved to everyone's satisfaction as yet. There's an ugly amount of coupling. We are yet to see how D's 'slack' implicit conversion handles in big projects with multiple developers and commercial deadlines.
> 
> I think the writing of DPD, the maturation of D towards 1.0, and the increasing number and sophistication of libraries like Mango will, over the next several months, inform on this debate. But it is *not* a done deal at the moment, and saying so makes the D community, IMO, look somewhat idiotic.
> 
> btw, all the foregoing is not aimed at Georg personally, just at the oft espoused idea that "D's superior to C++". It's not, albiet I look forward to 2005 being the year that it achieves the status of being so, or at least being a highly attractive alternative.

What can I say? You are right. And most of the things you refer to are, admittedly wishful thinking. No argument there. But it's a little like the football (american) team assembling on the field and murmuring "we will kick ass". Never mind the other guys are better and bigger. It's just what one does to keep up morale.

And dammit, if D ain't gonna kick ass! (One day, that is.) Heck, if we didn't thoroughly believe that, then we'd all skip this forum, read Imperfect C++, etc. and go back to C++.

I think we need this "my daddy is stronger than your daddy" attitude.

(Actually making this explicit and discussing it here may deteriorate the function of such thinking.) :-)

On Sun, 27 Feb 2005 23:18:59 +0000 (UTC), Kris wrote:

[snip]

> Here's another old & trivial example of this type of bogosity:
> 
> void print (char[] s);
> void print (wchar[] s);
> 
> {print ("bork");}
> 
> Because the char literal can be implicitly cast to wchar[], the compiler fails. One has to do this instead:
> 
> print (cast(char[]) "bork");
> 
> This is daft, Walter. And it hasn't been fixed a year later.

Kris, what do you think the compiler ought to do in this case, given only the information you have supplied above? I ask because I can't think of a decent alternative to failing (given that we are not allowed to have warning messages).

Upon seeing ...

  print ("bork");

the compiler is required to generate a call to a 'print' routine. It has
two to choose from. One requires char[] and the other wchar[]. What the
coder as told the compiler is that is has "bork" which is a string literal
in an unspecified encoding format. Because the coder hasn't specified the
format, the compiler tries the various possible ones available to it. So it
tries the obvious first one 'char[]' and gets a possible candidate routine.
It then tries 'wchar[]' and finds another candidate.
Now it has two routines which could be called - so which does it decide to
call? The compiler cannot know your intentions is such an ambiguous
situation, and since its too timid to assume one, it fails instead.

So it seems to me, that the coder is obliged to give a bit more information to the compiler to help it make better decisions. That could be decorating the literal with some sort of encoding notation, or maybe putting in a 'pragma' type thingy to tell the compiler that all undecorated string literals are all of type char[] so don't go implicitly trying other encoding formats, or maybe some thing else. In any case, the coder needs to take more responsibility rather than giving that up to the compiler writer.

> Oh, and let's not forget that D will implicitly, and silently, convert a long argument into an int or byte. Not even a peep from the compiler.

Yes. No this is a bit daft. Silently loosing data is bound to cause grief sooner or later. Here is a case in which the compiler is not timid and does make a unilateral decision, without alerting the coder.


[snip]

> I'm not saying that implicit-casting is necessarily bad, and I'm not saying that method-overloading is bad. I am saying the combination of the two leads to all sort of nastiness; some of which you've attempted to cover-up by implicitly hiding superclass method-names overloaded by a subclass, and which you just might cover up with an explicit-type-prefix on "literal" strings (such as w"wide-string").

And the alternative is ...??

> It shouldn't have to be like this. Surely there's a more elegant solution all round, both for the compiler and for the user? Less special-cases is better for everyone.

Yes, but have you any ideas as to what that might look like?

-- 
Derek
Melbourne, Australia
28/02/2005 10:38:33 AM

Matthew wrote:

>> The guys forced to do C++ for a living would cry big tears of envy. ;-) 

> <rant>
> Not so. I know you've a smiley there, but I really think this "C++ is too complicated, D is superior" is incredibly hasty, not to say naive.
> 
> I accept that from the compiler writer's perspective, D wins out over C++ in straightforwardness, implementatility, etc.etc.

[...]

> btw, all the foregoing is not aimed at Georg personally, just at the oft espoused idea that "D's superior to C++". It's not, albiet I look forward to 2005 being the year that it achieves the status of being so, or at least being a highly attractive alternative.
> </rant>

I'm not sure that D ("in itself") set out to be superior to C++ ?
I know that it set out to be *simpler*, and I think it has succeeded.
(at least in theory, in practice there are a few D "gotchas" still)

For people not having had to use C++, like myself, D is a nice mix
between the regular old C (it looks a lot similar, if not doing OOP)
and Java 2 (with the garbage collection and the single inheritance etc)


But is D more portable than C ? No.
Is it simpler to start with than Java* ? No.
And is it a just-drop-in replacement for C++ ? No.

Is it still worth learning and playing with anyway ? Yes! :-)


Though it would be nice if the show-stoppers could be fixed so
that a "D 1.0" can be released ? Even if it means dropping a
few features, like the array operations or the array literals...

Otherwise it runs a rather great risk of ending up as another
could-have-been-great idea/language, and be eaten by C++/Java* ?
And here on Mac OS X we already have one weirdo C-based language.

Just my 2 öre,
--anders


* Or C#, same difference. (I can run that language too, using Mono™)