Thread overview | ||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
November 01, 2008 Unofficial wish list status.(Nov 2008) | ||||
---|---|---|---|---|
| ||||
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: 187 Stack tracing (#26) 184 Reflection API (#6) 125 vectorization (#10) 105 Multiple return values (tuples (#28) 92 Multiple opCast per class (#24) 86 Debug check for null reference (#52) 81 Native AMD64 codegen (#36) 76 Short syntax for new (#18) 71 unit test after compilation (#1) 71 !in (#44) 67 extra compiler values (#19) 62 Return-type overloading (#49) 55 Explicit out/inout (#38) 52 Unit test isolation (#2) 52 Foreach on first/on last (#42) 48 Posix threads support native (#3) 45 Array masking (#11) 43 Array pushback/popback (#51) 42 better syntax for cast (#23) 42 Variadic arguments re-passing (#102) 40 Consistent struct/class sizeof (#40) 39 Explicit type initializers (#35) 38 L-Value return (#73) 35 associative arrays by index (#16) 34 unit test & code separation (#7) 34 black box unit testing (#8) 34 Named keyword arguments (#87) 33 coherent assoc. array syntax (#20) 33 Non-Static isExpression (#37) 32 Explicit module `friendship` (#43) 31 Pass value params byref (#34) 31 auto-member objects (#45) 31 struct constructor (#97) 30 Conditional syncronized (#30) 28 Unit test measurements (#9) 28 Explicit property keyword (#83) 26 Renaming ctor/dtor (#17) 25 Inline enum declaration (#76) 24 User-defined sync function (#31) 23 Small Exectables (#88) 22 if, while, true, false, int (#86) 21 proper cast operators (#21) 21 Iterators and Generators (#58) 20 Pascal like sets (#61) 20 interface to C++ (#71) 18 Built-in variant type (#56) 18 Precise names for floats (#62) 16 D library contest (#59) 16 Full lexical closures (#140) 15 No Postfix Array Declarations (#85) 15 range type (#106) 14 copy operator (#95) 14 Multi-Dimensional Allocation (#109) 13 Call log (#47) 13 Meta Information (#69) 13 modules must not rely on files (#84) 12 conv() and opConv (#66) 12 opCast overloading (#81) 12 garbage collection switch (#96) 12 Real C bitfields (#145) 11 inout variable and return (#60) 11 imag and comp FP types. (#63) 11 Finite sets (#72) 10 Improve module architecture (#64) 10 In flight exception detection (#101) 9 Against class instance sizeof (#48) 9 inline expansion (#67) 9 function inheritance (#92) 8 Relational class/array algebra (#65) 8 Parallel Scavenging GC (#80) 8 in for arrays (#160) 8 Get rid of const (#165) 7 date/time/datetime literal (#105) 7 void Class.Method() {} syntax (#146) 7 throws keyword (#173) 6 Statically check for == null (#98) 6 static foreach(scope/unscope) (#152) 5 Declaration in function calls (#74) 5 Efficient array opCatAssign (#148) 5 in for arrays (#161) 4 array in template arguments (#91) 4 support struct&array in switch (#99) 4 named tuple (#103) 4 Explicit out/inout/lazy (#110) 4 First-class continuations (#141) 4 Implicit New (#143) 4 suffix identifiers. (#168) 3 System.Windows.Forms (#93) 3 Reallocation Keyword (#108) 3 function call over network (#111) 3 Better UTF32 Support (#113) 3 Property shortcut (#144) 3 variable template(short syntax (#149) 3 template literal (#150) 3 tuple literal and append-op (#151) 3 {Cleaner Operator Overloading} (#166) 3 Remove const (#171) 3 Remove const (#172) 3 Tango to work with D2 (#179) 2 Manage .resources files (#70) 2 Multistep return (#75) 2 constant operater overloading (#100) 2 solve interdepend static this (#107) 2 Quick For Syntax (#142) 2 invariant function (#156) 2 Custom Attributes (#159) 2 Keyword Pow Operator (#162) 2 Custom Syntax (#163) 2 C++ Member Pointers (#167) 2 Property declarator (#174) 2 Voting in bugzilla for D. (#176) 1 consistant new (#77) 1 temp alias param specialize (#112) 1 remove initializers (#147) 1 __traits (#153) 1 ext property for basic types (#154) 1 temporary variable (#155) 1 Dynamic Conditional (#157) 1 constant member functions (#158) 1 templated constructors (#164) 1 New Switch Case Design (#170) 1 Remove SFINAE (#175) 1 Power operator (#177) 1 Enum string cast (#178) 0 Better Array Function Template (#169) |
November 01, 2008 Re: Unofficial wish list status.(Nov 2008) | ||||
---|---|---|---|---|
| ||||
Posted in reply to 4tuu4k002 | 4tuu4k002@sneakemail.com Wrote:
> 105 Multiple return values (tuples (#28)
> int, int getPoint();
> int a,b;
> a,b = getPoint();
Provided we have lvalue array literals, this can fit to general array operations rules:
int[] getPoint();
int a,b;
[a,b]=getPoint();
|
November 01, 2008 Re: Unofficial wish list status.(Nov 2008) | ||||
---|---|---|---|---|
| ||||
Posted in reply to ore-sama | ore-sama wrote:
> 4tuu4k002@sneakemail.com Wrote:
>
>> 105 Multiple return values (tuples (#28)
>> int, int getPoint();
>> int a,b;
>> a,b = getPoint();
>
> Provided we have lvalue array literals, this can fit to general array operations rules:
> int[] getPoint();
> int a,b;
> [a,b]=getPoint();
int code;
string msg;
[code, msg] = getError();
|
November 01, 2008 Re: Unofficial wish list status.(Nov 2008) | ||||
---|---|---|---|---|
| ||||
Posted in reply to KennyTM~ | On Sat, 01 Nov 2008 15:00:01 +0300, KennyTM~ <kennytm@gmail.com> wrote:
> ore-sama wrote:
>> 4tuu4k002@sneakemail.com Wrote:
>>
>>> 105 Multiple return values (tuples (#28)
>>> int, int getPoint();
>>> int a,b;
>>> a,b = getPoint();
>> Provided we have lvalue array literals, this can fit to general array operations rules:
>> int[] getPoint();
>> int a,b;
>> [a,b]=getPoint();
>
> int code;
> string msg;
>
> [code, msg] = getError();
This is now a tuple, its type is (int,string):
(code, msg) = getError(); // more consistent, but less appealing
|
November 01, 2008 Re: Unofficial wish list status.(Nov 2008) | ||||
---|---|---|---|---|
| ||||
Posted in reply to KennyTM~ | KennyTM~ Wrote:
> int code;
> string msg;
>
> [code, msg] = getError();
Uh... I thought about arrays. For this we need lvalue struct literals.
|
November 01, 2008 Re: Unofficial wish list status.(Nov 2008) | ||||
---|---|---|---|---|
| ||||
Posted in reply to Denis Koroskin | Denis Koroskin wrote:
> On Sat, 01 Nov 2008 15:00:01 +0300, KennyTM~ <kennytm@gmail.com> wrote:
>
>> ore-sama wrote:
>>> 4tuu4k002@sneakemail.com Wrote:
>>>
>>>> 105 Multiple return values (tuples (#28)
>>>> int, int getPoint();
>>>> int a,b;
>>>> a,b = getPoint();
>>> Provided we have lvalue array literals, this can fit to general array operations rules:
>>> int[] getPoint();
>>> int a,b;
>>> [a,b]=getPoint();
>>
>> int code;
>> string msg;
>>
>> [code, msg] = getError();
>
> This is now a tuple, its type is (int,string):
> (code, msg) = getError(); // more consistent, but less appealing
Right. It should be a tuple instead of an array for more generic variants.
I think this (x, y) = ... is just as good as [x, y] = ...
|
November 01, 2008 Re: Unofficial wish list status.(Nov 2008) | ||||
---|---|---|---|---|
| ||||
Posted in reply to KennyTM~ | KennyTM~ wrote:
> ore-sama wrote:
>> 4tuu4k002@sneakemail.com Wrote:
>>
>>> 105 Multiple return values (tuples (#28)
>>> int, int getPoint();
>>> int a,b;
>>> a,b = getPoint();
>>
>> Provided we have lvalue array literals, this can fit to general array operations rules:
>> int[] getPoint();
>> int a,b;
>> [a,b]=getPoint();
>
> int code;
> string msg;
>
> [code, msg] = getError();
Tuple!(int, "code", string, "msg") getError();
auto e = getError;
Andrei
|
November 01, 2008 Re: Unofficial wish list status.(Nov 2008) | ||||
---|---|---|---|---|
| ||||
Posted in reply to Andrei Alexandrescu | On Sat, 01 Nov 2008 19:04:16 +0300, Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org> wrote: > KennyTM~ wrote: >> ore-sama wrote: >>> 4tuu4k002@sneakemail.com Wrote: >>> >>>> 105 Multiple return values (tuples (#28) >>>> int, int getPoint(); >>>> int a,b; >>>> a,b = getPoint(); >>> >>> Provided we have lvalue array literals, this can fit to general array operations rules: >>> int[] getPoint(); >>> int a,b; >>> [a,b]=getPoint(); >> int code; >> string msg; >> [code, msg] = getError(); > > Tuple!(int, "code", string, "msg") getError(); > auto e = getError; > > > Andrei Imagine 'code' and 'msg' are already there as local variables and you want to reuse them. How should you do this? |
November 01, 2008 Re: Unofficial wish list status.(Nov 2008) | ||||
---|---|---|---|---|
| ||||
Posted in reply to Denis Koroskin | Denis Koroskin wrote:
> On Sat, 01 Nov 2008 19:04:16 +0300, Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org> wrote:
>
>> KennyTM~ wrote:
>>> ore-sama wrote:
>>>> 4tuu4k002@sneakemail.com Wrote:
>>>>
>>>>> 105 Multiple return values (tuples (#28)
>>>>> int, int getPoint();
>>>>> int a,b;
>>>>> a,b = getPoint();
>>>>
>>>> Provided we have lvalue array literals, this can fit to general array operations rules:
>>>> int[] getPoint();
>>>> int a,b;
>>>> [a,b]=getPoint();
>>> int code;
>>> string msg;
>>> [code, msg] = getError();
>>
>> Tuple!(int, "code", string, "msg") getError();
>> auto e = getError;
>>
>>
>> Andrei
>
> Imagine 'code' and 'msg' are already there as local variables and you want to reuse them. How should you do this?
I've been thinking of defining a simple function that binds to variable addresses and allows assignment from a tuple, in which case the code would be:
group(&code, &msg) = getError;
In "the future" we'll have variadic ref arguments, in which case the "&"s can be dropped:
group(code, msg) = getError;
Also in "the future" variable definitions will be expressions, in which case the code to define and assign code and msg becomes:
group(int code, string msg) = getError;
Andrei
|
November 01, 2008 Re: Unofficial wish list status.(Nov 2008) | ||||
---|---|---|---|---|
| ||||
Posted in reply to Andrei Alexandrescu | On Sat, 01 Nov 2008 19:33:01 +0300, Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org> wrote: > Denis Koroskin wrote: >> On Sat, 01 Nov 2008 19:04:16 +0300, Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org> wrote: >> >>> KennyTM~ wrote: >>>> ore-sama wrote: >>>>> 4tuu4k002@sneakemail.com Wrote: >>>>> >>>>>> 105 Multiple return values (tuples (#28) >>>>>> int, int getPoint(); >>>>>> int a,b; >>>>>> a,b = getPoint(); >>>>> >>>>> Provided we have lvalue array literals, this can fit to general array operations rules: >>>>> int[] getPoint(); >>>>> int a,b; >>>>> [a,b]=getPoint(); >>>> int code; >>>> string msg; >>>> [code, msg] = getError(); >>> >>> Tuple!(int, "code", string, "msg") getError(); >>> auto e = getError; >>> >>> >>> Andrei >> Imagine 'code' and 'msg' are already there as local variables and you want to reuse them. How should you do this? > > I've been thinking of defining a simple function that binds to variable addresses and allows assignment from a tuple, in which case the code would be: > > group(&code, &msg) = getError; > > In "the future" we'll have variadic ref arguments, in which case the "&"s can be dropped: > > group(code, msg) = getError; > > Also in "the future" variable definitions will be expressions, in which case the code to define and assign code and msg becomes: > > group(int code, string msg) = getError; > > > Andrei Hmmm, this is almost as nice (inspired by jQuery): $(code, msg) = getError(); // :) |
Copyright © 1999-2021 by the D Language Foundation