• 4tuu4k002 sneakemail.com (108/108) Feb 28 2007 Hi
• Daniel Keep (23/134) Feb 28 2007 Since it gives *no* definition of "faster", and since the new GC doesn't
• BCS (32/60) Feb 28 2007 I'm haveing evil thoughts...
• Frits van Bommel (7/20) Feb 28 2007 IIRC it was left on the list because the item covers associative arrays
• Don Clugston (8/33) Feb 28 2007 The name of the item should be changed to 'associative array
• Xinok (12/13) Feb 28 2007 On First / On Last, I'm thinking we could make use of the 'in' and 'out'...
• Henning Hasemann (6/19) Feb 28 2007 I dont think this would be a good idea since it would often

4tuu4k002 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:

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

Daniel Keep <daniel.keep.lists gmail.com> writes:

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/

BCS <BCS pathlink.com> writes:

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)

Frits van Bommel <fvbommel REMwOVExCAPSs.nl> writes:

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)

Don Clugston <dac nospam.com.au> writes:

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.

Xinok <xnknet gmail.com> writes:

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

Henning Hasemann <hhasemann web.de> writes:

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