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:

129  array initialization/literals
110  Reflection API
94  Stack tracing
88  Faster GC
85  vectorization
61  Multiple opCast per class
59  Short syntax for new
57  Multiple return values (tuples
57  Improved Foreach
55  readonly/const enforcement
54  unit test after compilation
52  extra compiler values
49  Native AMD64 codegen
43  Stack allocated classes.
43  !in
43  Debug check for null reference
42  Explicit out/inout
39  Unit test isolation
36  Return-type overloading
35  Posix threads support native
35  Array masking
33  Auto new-ing of classes
33  Foreach on first/on last
31  Explicit type initializers
29  better syntax for cast
29  Weak references/pointers
28  black box unit testing
28  Consistent struct/class sizeof
27  Pass value params byref
26  unit test & code separation
26  associative arrays by index
25  auto-member objects
24  coherent assoc. array syntax
24  Templates in classes
22  Renaming ctor/dtor
21  Header File generation by DMD
21  Array pushback/popback
20  Unit test measurements
20  Non-Static isExpression
20  Explicit module `friendship`
20  Experimental d compiler
19  proper cast operators
19  User-defined sync function
15  Conditional syncronized
15  Eigenpoll fix
15  L-Value return
14  opIn
14  Iterators and Generators
12  OS X Build
11  Built-in variant type
11  D library contest
11  Named keyword arguments
10  imag and comp FP types.
9  inout variable and return
9  Pascal like sets
9  Precise names for floats
9  struct literal/initialization
9  Explicit property keyword
8  Call log
8  Pascal casing for methods, mod
8  modules must not rely on files
8  struct constructor
7  Against class instance sizeof
7  Add native string type
7  conv() and opConv
7  Meta Information
7  Small Exectables
6  Improve module architecture
6  Finite sets
6  function inheritance
5  Relational class/array algebra
5  inline expansion
5  No Postfix Array Declarations
5  if, while, true, false, int
5  Variadic arguments re-passing
4  interface to C++
4  Declaration in function calls
4  Inline enum declaration
4  This list makes a difference?
4  Variadic template arguments
4  In flight exception detection
3  opCast overloading
3  System.Windows.Forms
3  copy operator
3  support struct&array in switch
2  Multistep return
2  named tuple
1  Manage .resources files
1  consistant new
1  Parallel Scavenging GC
1  array in template arguments
1  garbage collection switch
1  Statically check for == null
1  constant operater overloading
1  deduce function return type
1  date/time/datetime literal
1  range type
1  solve interdepend static this
1  Multi-Dimensional Allocation
1  Explicit out/inout/lazy
1  function call over network
0  allow change self interface(?)
0  Explicit 'property' keyword
0  Reallocation Keyword

4tuu4k002@sneakemail.com wrote:
> 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:
> 
> 129  array initialization/literals

Well, we have that, don't we?

> 110  Reflection API
> 94  Stack tracing
> 88  Faster GC

Since it gives *no* definition of "faster", and since the new GC doesn't scan non-pointers, we therefore have a "faster" GC. :P

> 85  vectorization
> 61  Multiple opCast per class
> 59  Short syntax for new
> 57  Multiple return values (tuples
> 57  Improved Foreach

So close; only need that "else" clause now...

> 55  readonly/const enforcement
> 54  unit test after compilation
> 52  extra compiler values
> 49  Native AMD64 codegen
> 43  Stack allocated classes.

Kinda sorta have this.

> 43  !in
> 43  Debug check for null reference
> 42  Explicit out/inout
> 39  Unit test isolation
> 36  Return-type overloading
> 35  Posix threads support native
> 35  Array masking
> 33  Auto new-ing of classes
> 33  Foreach on first/on last
> 31  Explicit type initializers
> 29  better syntax for cast
> 29  Weak references/pointers

Aren't weak refs possible now?  I think I remember seeing an implementation somewhere...

> 28  black box unit testing
> 28  Consistent struct/class sizeof
> 27  Pass value params byref
> 26  unit test & code separation
> 26  associative arrays by index
> 25  auto-member objects
> 24  coherent assoc. array syntax
> 24  Templates in classes
> 22  Renaming ctor/dtor
> 21  Header File generation by DMD

Uhh, haven't we had this for *ages*?  dmd -H

> 21  Array pushback/popback
> 20  Unit test measurements
> 20  Non-Static isExpression
> 20  Explicit module `friendship`
> 20  Experimental d compiler
> 19  proper cast operators
> 19  User-defined sync function
> 15  Conditional syncronized
> 15  Eigenpoll fix
> 15  L-Value return
> 14  opIn

Got that.

> 14  Iterators and Generators
> 12  OS X Build
> 11  Built-in variant type
> 11  D library contest
> 11  Named keyword arguments
> 10  imag and comp FP types.
> 9  inout variable and return
> 9  Pascal like sets
> 9  Precise names for floats
> 9  struct literal/initialization

Have this, too (not the same syntax, but pretty close).

> 9  Explicit property keyword
> 8  Call log
> 8  Pascal casing for methods, mod

We don't have this, and thank god!  Compiler-enforced function casing?!
 Who votes for this stuff?

> 8  modules must not rely on files
> 8  struct constructor
> 7  Against class instance sizeof
> 7  Add native string type
> 7  conv() and opConv
> 7  Meta Information
> 7  Small Exectables
> 6  Improve module architecture
> 6  Finite sets
> 6  function inheritance
> 5  Relational class/array algebra
> 5  inline expansion

Looks like compile-time function evaluation.

> 5  No Postfix Array Declarations
> 5  if, while, true, false, int
> 5  Variadic arguments re-passing
> 4  interface to C++
> 4  Declaration in function calls
> 4  Inline enum declaration
> 4  This list makes a difference?
> 4  Variadic template arguments

Yup.

> 4  In flight exception detection
> 3  opCast overloading
> 3  System.Windows.Forms
> 3  copy operator
> 3  support struct&array in switch
> 2  Multistep return
> 2  named tuple
> 1  Manage .resources files
> 1  consistant new
> 1  Parallel Scavenging GC
> 1  array in template arguments
> 1  garbage collection switch
> 1  Statically check for == null
> 1  constant operater overloading
> 1  deduce function return type

Easy as pie, now.

> 1  date/time/datetime literal
> 1  range type
> 1  solve interdepend static this
> 1  Multi-Dimensional Allocation
> 1  Explicit out/inout/lazy
> 1  function call over network
> 0  allow change self interface(?)
> 0  Explicit 'property' keyword
> 0  Reallocation Keyword

The above ones that are actually complete should probably be removed.

	-- Daniel

-- 
Unlike Knuth, I have neither proven or tried the above; it may not even make sense.

v2sw5+8Yhw5ln4+5pr6OFPma8u6+7Lw4Tm6+7l6+7D i28a2Xs3MSr2e4/6+7t4TNSMb6HTOp5en5g6RAHCP  http://hackerkey.com/

Daniel Keep wrote:
> 
> 4tuu4k002@sneakemail.com wrote:
> 
>>129  array initialization/literals
> 
> 
> Well, we have that, don't we?
> 

yes, and IIRC it's broken

> 
>>57  Improved Foreach
> 
> So close; only need that "else" clause now...
> 

I'm haveing evil thoughts...

foreach(K key, V val;
	delegate int(int delegate(inout K key,inout V value)
	{
		...
	})
{
}

that works, so it the delegate has no state in local vars

auto tmp = delegate int(int delegate(inout K key,inout V value)
	{
		...
	}

tmp((inout K key,inout V value)
{
	... // on first
});

foreach(key, value; tmp)
{
	... // the rest
}

> 
>>33  Foreach on first/on last

see above

>>21  Header File generation by DMD
> 
> 
> Uhh, haven't we had this for *ages*?  dmd -H
> 

I think htod is more what is wanted

> 
>>20  Experimental d compiler

he, he, he... <G>

>>14  Iterators 

see above (sort of)

>> and Generators

Ah.. err.. I'm not that evil

>>10  imag and comp FP types.

creal, ireal, or did I not read that correctly

>>7  conv() and opConv

opApply??

>>3  copy operator

see above

>>1  function call over network

I had somthing like that working at one point. (total hack)

Daniel Keep wrote:
> 
> 4tuu4k002@sneakemail.com wrote:
>>
>> 129  array initialization/literals
> 
> Well, we have that, don't we?

IIRC it was left on the list because the item covers associative arrays as well, and those aren't implemented yet.

>> 29  Weak references/pointers
> 
> Aren't weak refs possible now?  I think I remember seeing an
> implementation somewhere...

You can hide them with malloc(), but that's about all. The Object.notify* methods use this technique, IIRC.

>> 21  Header File generation by DMD
> 
> Uhh, haven't we had this for *ages*?  dmd -H

Perhaps it's still here because it doesn't remove all code? (IIRC it leaves inlinable functions intact)

On First / On Last, I'm thinking we could make use of the 'in' and 'out' keywords for this, something like with functions:

foreach(arg; arr)
in{
}
out{
}
body{
}

for the 'in' block, arg[0] would be used.
for the 'out' block, arg[length-1] would be used.

4tuu4k002@sneakemail.com wrote:
> 57  Improved Foreach

Frits van Bommel wrote:
> Daniel Keep wrote:
>>
>> 4tuu4k002@sneakemail.com wrote:
>>>
>>> 129  array initialization/literals
>>
>> Well, we have that, don't we?
> 
> IIRC it was left on the list because the item covers associative arrays as well, and those aren't implemented yet.

The name of the item should be changed to 'associative array initialisation/literals'.

> 
>>> 29  Weak references/pointers
>>
>> Aren't weak refs possible now?  I think I remember seeing an
>> implementation somewhere...
> 
> You can hide them with malloc(), but that's about all. The Object.notify* methods use this technique, IIRC.
> 
>>> 21  Header File generation by DMD
>>
>> Uhh, haven't we had this for *ages*?  dmd -H
> 
> Perhaps it's still here because it doesn't remove all code? (IIRC it leaves inlinable functions intact)

Maybe, but if that is what people want, it should be removed from the list -- I think they're asking for something impossible.

Frankly, I find that list pretty annoying. There are lots of things on it which are ambiguous, some which have already been implemented, and some are really misguided ideas.

On Thu, 01 Mar 2007 00:14:14 -0500
Xinok <xnknet@gmail.com> wrote:

> On First / On Last, I'm thinking we could make use of the 'in' and 'out' keywords for this, something like with functions:
> 
> foreach(arg; arr)
> in{
> }
> out{
> }
> body{
> }
> 
> for the 'in' block, arg[0] would be used.
> for the 'out' block, arg[length-1] would be used.

I dont think this would be a good idea since it would often be confused with pre- and postconditions, so other names like first{ } and last{ } would be better.

Henning