www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Unofficial wish list status.

reply 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:

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

-- Inline enum declaration
I think this should be unlocked using a keyword. For example:
void func(decl enum{Show, Hide}sw);
But I like that D doesn't require a semi-colon after an enum declaration.

-- Return Type Overloading
Their design is a bit awkward, and it can be improved a lot IMO. Overloading a
function by it's return type should be no different than overloading the cast
operators in a class.

int func(); short func(); float func();

int a = func();
// In the example, they claim this is ambiguous. The compiler should be smart
enough to go with the closest type 'int'

a = call(int)func();
// A 'call' keyword isn't necessary. Using a typecast would work just fine:
a = cast(int)func();


-- Multiple Return Values
I think the best way to tackle this is with tuples.

- Make a way to declare tuples without the need for declaring a template
- Allow naming tuple arguments.
- Create a simple syntax for returning multiple values

tuple(int a, int b) func(){
// Declare a tuple without the need for a template
// Allow naming tuple arguments
	return 15, 30;
	// Simple syntax for returning multiple values
}

int main(){
	auto ret = func();
	writefln(ret.a + ret.b);

	writefln(func().b);
}


-- array initialization/literals
They gave this design for initalizing associative arrays:
int[char[]] aa = ["one":1, "two":2, "three":3]

This design would be a problem if you used a conditional ? : for the index. My
design:
int[char[]] aa = [["one"] = 1, ["two"] = 2, ["three"] = 3];
int[][int] aa = [[0] = [15, 30], [1] = [45, 60, 75]];
int[int][int] aa = [[0][1] = 15, [2][3] = 30]; // This would be nice, though I'm
not sure if it would work


I added two wishes of my own:
- 'Renew' keyword - A keyword for reallocation
http://all-technology.com/eigenpolls/dwishlist/index.php?it=108

- Multi-dimensional Allocation
http://all-technology.com/eigenpolls/dwishlist/index.php?it=109
Dec 31 2006
next sibling parent reply janderson <askme me.com> writes:
Some good points.  See my thoughts on your thoughts below...

Xinok wrote:
<snip>

 -- Return Type Overloading
 Their design is a bit awkward, and it can be improved a lot IMO. Overloading a
 function by it's return type should be no different than overloading the cast
 operators in a class.
 
 int func(); short func(); float func();
 
 int a = func();
 // In the example, they claim this is ambiguous. The compiler should be smart
 enough to go with the closest type 'int'


What about?
byte func(); short func(); float func();

int a = func();

I think in these cases the compiler should just say its ambiguous and 
recommend the user cast to the type they want. ie:

Error: func() overload is ambiguous.  Could be byte func() or short 
func().  You may indicate which one by use of a cast.

<snip>


 -- array initialization/literals
 They gave this design for initalizing associative arrays:
 int[char[]] aa = ["one":1, "two":2, "three":3]
 
 This design would be a problem if you used a conditional ? : for the index. My
design:
 int[char[]] aa = [["one"] = 1, ["two"] = 2, ["three"] = 3];
 int[][int] aa = [[0] = [15, 30], [1] = [45, 60, 75]];
 int[int][int] aa = [[0][1] = 15, [2][3] = 30]; // This would be nice, though
I'm
 not sure if it would work


I don't like this format it way to long so it doesn't save you much, you 
might as well do this:
int[char[]] aa; aa["one"] = 1; aa["two"] = 2; aa["three"] = 3;


I don't think conditionals would be to much of a problem, they could be 
bracketed:

int[][int] aa = [(X?Y:Z):[15, 30], 1:[45, 60, 75]];


 
 
 I added two wishes of my own:
 - 'Renew' keyword - A keyword for reallocation
 http://all-technology.com/eigenpolls/dwishlist/index.php?it=108


C++ doesn't have a renew because its difficult to work out what would 
happen to the objects (would they be recreated -> copied using the copy 
constructor?).  It would be a good idea to describe how it would work 
and all the edge cases.

See:
http://cpptips.hyperformix.com/cpptips/renew.txt

(This is a common interview question "Why is there no renew operation 
like C's realloc function in C++?")

I think this case is rare enough in D, that this just becomes bloat. 99% 
  of the time D's dynamic arrays will be fine, although if we didn't 
have D's arrays I'd be all for it.


 
 - Multi-dimensional Allocation
 http://all-technology.com/eigenpolls/dwishlist/index.php?it=109


This is a good idea.
Jan 01 2007
parent Bill Baxter <dnewsgroup billbaxter.com> writes:
janderson wrote:


 - Multi-dimensional Allocation
 http://all-technology.com/eigenpolls/dwishlist/index.php?it=109


 


How does this differ from

int[][][] bar;
...
bar = new int[][][](5,20,30);

(http://www.digitalmars.com/d/expression.html#NewExpression)

--bb
Jan 01 2007
prev sibling parent reply Chris Nicholson-Sauls <ibisbasenji gmail.com> writes:
Xinok wrote:

 -- array initialization/literals
 They gave this design for initalizing associative arrays:
 int[char[]] aa = ["one":1, "two":2, "three":3]
 
 This design would be a problem if you used a conditional ? : for the index. My
design:
 int[char[]] aa = [["one"] = 1, ["two"] = 2, ["three"] = 3];
 int[][int] aa = [[0] = [15, 30], [1] = [45, 60, 75]];
 int[int][int] aa = [[0][1] = 15, [2][3] = 30]; // This would be nice, though
I'm
 not sure if it would work


I believe the choice of the colon for this was based on the syntax for static
struct 
initializers:








But personally I think something like this would work well for assoc's:






It makes a new operator, aye, but I don't believe a '=>' is used anywhere else.
 It also 
should not be ambiguous for the compiler, as an array literal's type is taken
from the 
first element, and this would make the first element a key=>value of type
char[]=>int.

-- Chris Nicholson-Sauls
Jan 01 2007
parent reply Xinok <xnknet gmail.com> writes:
-- Renew
I don't understand why you can't simply use a low-level operation like memcpy?
The
only difference is the memory address will change. The biggest issue is that it
might break pointers, but this is still an issue whether you use renew or not:

int* ptr = new int[5];
int* b = &ptr[3];
int* tmp = new int[10];
for(int i = 0; i < 5; i++) tmp[i] = ptr[i];
delete ptr; ptr = tmp;
// Oops! pointer 'b' is now broken

If it's really that important, then perhaps defining a 'renew' operator is the
way
to go, something which is more efficient than a copy constructor.
class PP{
    opRenew(void* old){ } // The argument could be the memory address in which
the
object used to be located
}

-- Associative Array Initalization
I think my design makes very much sense. You're telling the compiler which index
you want to initalize. What better way to do that than to use []?
int[int] arr = [[0] = 15, [1] = 30, [2] = 45];

In addition, because I use the assignment operator =, it's logical to do this:
int[][int] arr = [[0] = [15, 30, 45], [1] = [60, 75]];

The expression is contained within the square brackets [], so you aren't limited
to what you can do with the expression:
int a = 15;
int[int] arr = [[a = 30] = 45];
int[int] b = [[a = arr[30] > 0 ? 1 : 2] = 12];

Using : for structs works because you provide a symbol, not an expression.
struct SS { int a, b, c; }
static SS obj = { a : 15, b : 45 }; // 'a' is a symbol
This is the same reason using : works for specialization.


-- Multi-Dimensional Allocation

 How does this differ from

 int[][][] bar;
 ...
 bar = new int[][][](5,20,30);


The whole purpose is so you could use it with pointers. This doesn't seem to
work:
int** ptr = new int[][](5, 20);
Jan 01 2007
parent Chris Nicholson-Sauls <ibisbasenji gmail.com> writes:
Xinok wrote:

 -- Renew
 I don't understand why you can't simply use a low-level operation like memcpy?
The
 only difference is the memory address will change. The biggest issue is that it
 might break pointers, but this is still an issue whether you use renew or not:
 
 int* ptr = new int[5];
 int* b = &ptr[3];
 int* tmp = new int[10];
 for(int i = 0; i < 5; i++) tmp[i] = ptr[i];
 delete ptr; ptr = tmp;
 // Oops! pointer 'b' is now broken
 
 If it's really that important, then perhaps defining a 'renew' operator is the
way
 to go, something which is more efficient than a copy constructor.
 class PP{
     opRenew(void* old){ } // The argument could be the memory address in which
the
 object used to be located
 }
 
 -- Associative Array Initalization
 I think my design makes very much sense. You're telling the compiler which
index
 you want to initalize. What better way to do that than to use []?
 int[int] arr = [[0] = 15, [1] = 30, [2] = 45];
 
 In addition, because I use the assignment operator =, it's logical to do this:
 int[][int] arr = [[0] = [15, 30, 45], [1] = [60, 75]];
 
 The expression is contained within the square brackets [], so you aren't
limited
 to what you can do with the expression:
 int a = 15;
 int[int] arr = [[a = 30] = 45];
 int[int] b = [[a = arr[30] > 0 ? 1 : 2] = 12];
 
 Using : for structs works because you provide a symbol, not an expression.
 struct SS { int a, b, c; }
 static SS obj = { a : 15, b : 45 }; // 'a' is a symbol
 This is the same reason using : works for specialization.
 
 
 -- Multi-Dimensional Allocation

 How does this differ from

 int[][][] bar;
 ...
 bar = new int[][][](5,20,30);


 
 The whole purpose is so you could use it with pointers. This doesn't seem to
work:
 int** ptr = new int[][](5, 20);


Except that as of last release (and I actually think it was a good idea) arrays
are no 
longer implicitly cast'able to pointers, so this still wouldn't work directly. 
And the 
canonical means of acquiring a pointer from an array is to use the .ptr
property, which is 
always a single indirection pointer even for multidimensional arrays.  (This,
presumably, 
would change if we later acquire matrices such as 'int[5, 20]'.)

-- Chris Nicholson-Sauls
Jan 01 2007