Thread overview | |||||||||
---|---|---|---|---|---|---|---|---|---|
|
January 01, 2007 Unofficial wish list status. | ||||
---|---|---|---|---|
| ||||
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 |
January 01, 2007 Re: Unofficial wish list status. | ||||
---|---|---|---|---|
| ||||
Posted in reply to 4tuu4k002 | 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 |
January 01, 2007 Re: Unofficial wish list status. | ||||
---|---|---|---|---|
| ||||
Posted in reply to Xinok | 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. |
January 01, 2007 Re: Unofficial wish list status. | ||||
---|---|---|---|---|
| ||||
Posted in reply to janderson | 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 |
January 01, 2007 Re: Unofficial wish list status. | ||||
---|---|---|---|---|
| ||||
Posted in reply to Xinok | 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:
# struct S {
# int i ;
# char[] t ;
# }
#
# static S myS = {i: 42, t: "hello"};
But personally I think something like this would work well for assoc's:
# int[char[]] aa = [
# "one" => 1 ,
# "two" => 2 ,
# "three" => 3
# ]
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
|
January 01, 2007 Re: Unofficial wish list status. | ||||
---|---|---|---|---|
| ||||
Posted in reply to Chris Nicholson-Sauls | -- 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);
|
January 01, 2007 Re: Unofficial wish list status. | ||||
---|---|---|---|---|
| ||||
Posted in reply to Xinok |
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
|
Copyright © 1999-2021 by the D Language Foundation