• 12tkvvb02 sneakemail.com (55/55) Jan 31 2006 Hi
• nick (10/11) Jan 31 2006 So, what happens if you have
• Oskar Linde (21/36) Feb 01 2006 In the above example, the type of w is still Widget, so the overload

12tkvvb02 sneakemail.com writes:

Hi

This is the monthly status for the unofficial d wish list: 
http://all-technology.com/eigenpolls/dwishlist/

Right now the wish list looks like this:

76  array initialization/literals
54  Reflection API
50  vectorization
46  Faster GC 
46  Stack tracing
40  Short syntax for new
36  Improved Foreach
35  unit test after compilation
32  Multiple opCast per class
31  extra compiler values
29  Unit test isolation 
25  Posix threads support native
25  Array masking
25  Multiple return values (tuples
24  Auto new-ing of classes
24  readonly/const enforcement
22  black box unit testing
22  Native AMD64 codegen
22  Stack allocated classes.
21  better syntax for cast
20  Explicit out/inout
20  Foreach on first/on last
19  unit test & code separation
19  Unit test measurements
19  associative arrays by index
19  coherent assoc. array syntax
19  Explicit type initializers
19  !in
18  unit test coverage 
18  Renaming ctor/dtor
16  Weak references/pointers
16  Consistent struct/class sizeof
14  Debug check for null reference
13  proper cast operators
13  Pass value params byref
12  User-defined sync function
12  Templates in classes
12  Header File generation by DMD
11  Conditional syncronized
11  auto-member objects
11  Return-type overloading
10  Non-Static isExpression
10  Explicit module `friendship`
10  Experimental d compiler
6  Call log
6  Eigenpoll fix
6  Array pushback/popback
5  Against class instance sizeof
2  OS X Build
2  opIn
1  Built-in variant type

nick <nick.atamas gmail.com> writes:

12tkvvb02 sneakemail.com wrote:

 11  Return-type overloading

So, what happens if you have
// Button, Slider, Panel all derive from Widget
Button foo(){return button;}
Slider foo(){return slider;}
Panel foo(){return panel;}

Widget w = A.getPanel("keyValue");
w = foo(); //must deffer to runtime!?

Doesn't double dispatch solve the overloaded return types problem? Maybe 
there is a case where it doesn't.

Oskar Linde <oskar.lindeREM OVEgmail.com> writes:

nick wrote:
 12tkvvb02 sneakemail.com wrote:
 
 11  Return-type overloading

 
 So, what happens if you have
 // Button, Slider, Panel all derive from Widget
 Button foo(){return button;}
 Slider foo(){return slider;}
 Panel foo(){return panel;}
 
 Widget w = A.getPanel("keyValue");
 w = foo(); //must deffer to runtime!?
 
 Doesn't double dispatch solve the overloaded return types problem? Maybe 
 there is a case where it doesn't.

In the above example, the type of w is still Widget, so the overload 
would be ambiguous. I don't think any suggestion includes runtime 
resolution. I agree with you that there are other ways to solve the 
problem, though. I think return type overloading introduces many more 
problem than it potentially solves. A better idiom for the above example 
would be to use an out parameter.

The language is built upon the fact that each subexpression has a 
computable type. From this, the type of all expressions are deducible. 
Breaking this would complicate many things and reduce the expressiveness 
of template programming and more. With return type overloading, I 
believe you can even make arbitrarily complicated search graphs the 
compile has to traverse to deduce the type of an expression. I have a 
hard time seeing this as a good thing.

D already has return type overloading of sorts in one case: undecorated 
string literals. This tiny break of the type deduction rule has already 
introduced many problems and inconsistencies.

Why return type overloading such a requested feature that it is placed 
on the eigenvalue weighted second place on the wish list? What are the 
problems that return type overloading would solve?

/Oskar