www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - new initializer syntax (was TempAlloc review starts now)

reply Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
 But its usage as expression is not the most nice, so it's probably better to
 disallow this usage:

 void foo(int[] a) {}
 main() {
     foo(new[5] = 5);
 }


Might as well change foo to accept a size_t length and initializer,
and let it create an array on the stack or heap, whichever it thinks
is more efficient or safer. Why pass a new heap-allocated array which
you don't have the handle to outside of foo? What's the use-case for
this example?


 There is a very simple syntax, nice and clean:

 // doesn't initialize foo1
 auto foo1 = new uint[5] = void;

 // initializes the dynamic array to 5, avoiding a double initialization
 auto foo2 = new uint[5] = 10;

 // works for nD arrays too
 auto mat1 = new double[][][](n1,n2,n3) = 0.0;


I thought about "void new", but I'd rather drop that idea. There's
also that opinion that letting 'new' into the language was a mistake.
I wouldn't mind a template instead of syntax sugar. I'd be fine with:

auto foo = voidNew!(float[][])(4, 10);         // float[10][4], no initializer
auto bar = initNew!(float[][])(4, 10, 5.5);  // float[10][4], all
initialized to 5.5

or make the initializer a CT argument, I think this would be more readable:
auto bar = initNew!(float[][], 5.5)(4, 10);  // float[10][4], all
initialized to 5.5

No need to mess with the compiler, can be implemented with D's
template features. We can have this implemented and unittested in a
day, compared to hacking the compiler and worrying about bugs.
Jun 05 2011
parent reply bearophile <bearophileHUGS lycos.com> writes:
Andrej Mitrovic:


 Why pass a new heap-allocated array which
 you don't have the handle to outside of foo? What's the use-case for
 this example?


It's a minimal example to show a syntax, it's not an use case.



 No need to mess with the compiler,


With this attitude probably you are able to remove half of the stuff present in
D today (and sometimes this is good. After all this time I have changed my mind
a little and I don't think associative arrays are so good as built-in in a
system language. What's needed is just a general built-in syntax to define AA
literals, a syntax usable for user-defined types too).

Bye,
bearophile
Jun 05 2011
parent reply Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
On 6/6/11, bearophile <bearophileHUGS lycos.com> wrote:

 With this attitude probably you are able to remove half of the stuff present
 in D today.


:) Well I was talking about adding features, not turning existing ones
to library code.

Another benefit of adding a feature as a library function first
instead of a language feature is you get to test the function first
and figure out if you really use it that often. If it becomes too
tiring to use the function then implementing some syntax sugar might
be better.
Jun 05 2011
parent reply Daniel Gibson <metalcaedes gmail.com> writes:
Am 06.06.2011 03:47, schrieb Andrej Mitrovic:

 On 6/6/11, bearophile <bearophileHUGS lycos.com> wrote:

 With this attitude probably you are able to remove half of the stuff present
 in D today.


 
 :) Well I was talking about adding features, not turning existing ones
 to library code.
 
 Another benefit of adding a feature as a library function first
 instead of a language feature is you get to test the function first
 and figure out if you really use it that often. If it becomes too
 tiring to use the function then implementing some syntax sugar might
 be better.


But maybe you don't use it that often because using the function is too
tiring ;)
Jun 05 2011
next sibling parent Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
On 6/6/11, Daniel Gibson <metalcaedes gmail.com> wrote:

 But maybe you don't use it that often because using the function is too
 tiring ;)


Well with Andrei's proposed "makeUninitializedArray!()" I wouldn't be
surprised. :P
Jun 05 2011
prev sibling parent Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
Referring to: http://d.puremagic.com/issues/show_bug.cgi?id=3383#c1
Jun 05 2011