• Tomasz Sowi&#324;ski <tomeksowi wp.pl> Mar 10 2009
• Christopher Wright <dhasenan gmail.com> Mar 10 2009
• "Nick Sabalausky" <a a.a> Mar 10 2009

Tomasz Sowi&#324;ski <tomeksowi wp.pl> writes:

Sergey Gromov Wrote:

 Thu, 05 Mar 2009 07:38:23 -0500, Tomasz Sowiński wrote:
 
 Walter Bright Wrote:
 
 It looks nice, but has a subtle and disastrous problem. In D, arguments 
 are fully resolved *before* overloading is done. If some of the 
 overloads have with declarations, then there's a nightmarish problem of 
 trying to mix overloading and argument resolution together.


 Not sure if I understand right. Can you write up a simple example of the
nightmare?
 
 Tomek


 I think Walter means that types of argument expressions are determined
 first, and only then a set of compatible overloads is composed.  Say you
 have
 
 enum Foo { one, two }
 int one;
 
 void bar(int x);  // (1)
 void bar(with Foo x);  // (2)
 
 bar(one);
 
 Currently, D will determine that expression 'one' is of type int, then
 search for bar(int) or compatible, and will find (1).  With your
 proposal, you must first find all 'bar's, determine that *some* of them
 have 'with' arguments, and now what?  Infer type for the first argument
 differently for (1) and (2), so that for (1) it's int, and for (2) it's
 Foo?  Or add the Foo to the scope, so that the first argument is of type
 Foo even for (1)?  I can't see a good solution.


A blunt one would be screaming out an error whenever the compiler has trouble
choosing an overload. Would it be too hard to live with?

Christopher Wright <dhasenan gmail.com> writes:

Sorry about the name...

Tomasz Sowiński wrote:
 A blunt one would be screaming out an error whenever the compiler has trouble
choosing an overload. Would it be too hard to live with?


For programmers? It would be ugly.

For the compiler? It would be ugly, and result in a lot of 
special-casing, I feel. With current with statements, you start a new 
scope and add a bunch of symbols to it. Using this proposed with 
statement syntax, you don't create a new scope, so you have to add a 
step or three to resolving symbols.

Also, you'd have to find all possible overloads of a function and do 
some semantic analysis on them before you could resolve the arguments. 
Overload resolution becomes a lot more difficult.

And what does the programmer gain? Very little. People seldom use enums, 
I think.

"Nick Sabalausky" <a a.a> writes:

"Christopher Wright" <dhasenan gmail.com> wrote in message 
news:gp6p96$2dp9$1 digitalmars.com...
 Sorry about the name...

 Tomasz Sowi&#324;ski wrote:
 A blunt one would be screaming out an error whenever the compiler has 
 trouble choosing an overload. Would it be too hard to live with?


 For programmers? It would be ugly.

 For the compiler? It would be ugly, and result in a lot of special-casing, 
 I feel. With current with statements, you start a new scope and add a 
 bunch of symbols to it. Using this proposed with statement syntax, you 
 don't create a new scope, so you have to add a step or three to resolving 
 symbols.

 Also, you'd have to find all possible overloads of a function and do some 
 semantic analysis on them before you could resolve the arguments. Overload 
 resolution becomes a lot more difficult.

 And what does the programmer gain? Very little. People seldom use enums, I 
 think.


I use enums all the time. But I don't mind prepending "MyEnumType." to enum 
literals. It would be nice to have a shortcut in clear-cut cases, but if it 
meant a bunch of special casing and such, I can certainly live without it.