www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Unofficial wish list status.

reply 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
Jan 31 2006
parent reply 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.
Jan 31 2006
parent 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
Feb 01 2006