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