www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Re: The demise of T[new]

reply Yigal Chripun <yigal100 gmail.com> writes:
Walter Bright Wrote:


 The purpose of T[new] was to solve the problems T[] had with passing T[] 
 to a function and then the function resizes the T[]. What happens with 
 the original?
 
 The solution we came up with was to create a third array type, T[new], 
 which was a reference type.
 
 Andrei had the idea that T[new] could be dispensed with by making a 
 "builder" library type to handle creating arrays by doing things like 
 appending, and then delivering a finished T[] type. This is similar to 
 what std.outbuffer and std.array.Appender do, they just need a bit of 
 refining.
 
 The .length property of T[] would then become an rvalue only, not an 
 lvalue, and ~= would no longer be allowed for T[].
 
 We both feel that this would simplify D, make it more flexible, and 
 remove some awkward corner cases like the inability to say a.length++.
 
 What do you think?



I think that Arrays and AAs need to be removed from the language. 
I prefer to have a collections framework as part of Phobos without special
cases in the language for specific containers. 

The only thing that needs to remain on the language side is support for user
defined literals and operators so that it would be straight forward to use (as
opposed to the clumsiness of C++). This syntax sugar is the *only* benefit of
built in types and this should be possible to have without cluttering the
language.

such a framework would ideally support polymorphism. 

List!(Foo) list = new Array!(Foo); // instead of Foo[new]

auto arr = new Array!(Foo);
...
auto slice = arr[1..4]; // slice is a Range as in Andrei's Ranges in Phobos

Foo[] a; // compile-error Foo[] is not a type, use Range!Foo instead

Foo[3] a; // this is still perfectly legal
Oct 19 2009
parent reply BCS <none anon.com> writes:
Hello Yigal,


 I think that Arrays and AAs need to be removed from the language. I
 prefer to have a collections framework as part of Phobos without
 special cases in the language for specific containers.



If it can be assured that all the current array ops will get inlined is all 
cases and can result in identical asm I'd be willing to consider this.


 List!(Foo) list = new Array!(Foo); // instead of Foo[new]



For me to not dislike the idea you would also need to find a cleaner syntax.
Oct 19 2009
parent reply Yigal Chripun <yigal100 gmail.com> writes:
On 19/10/2009 19:10, BCS wrote:

 Hello Yigal,


 I think that Arrays and AAs need to be removed from the language. I
 prefer to have a collections framework as part of Phobos without
 special cases in the language for specific containers.



 If it can be assured that all the current array ops will get inlined is
 all cases and can result in identical asm I'd be willing to consider this.


 List!(Foo) list = new Array!(Foo); // instead of Foo[new]



 For me to not dislike the idea you would also need to find a cleaner
 syntax.




currently, AAs and arrays are implemented in the run-time. What I 
suggest is to move them to the stdlib. I don't see how such a move can 
impact performance which you're concerned with above. on the contrary, 
moving these types outside the runtime will make it easier to improve 
their implementations.

regarding syntax, what's cleaner than calling an array an "Array"?
T[new] is less clear and hackish.
Oct 19 2009
parent reply BCS <none anon.com> writes:
Hello Yigal,


 On 19/10/2009 19:10, BCS wrote:
 

 Hello Yigal,
 

 I think that Arrays and AAs need to be removed from the language. I
 prefer to have a collections framework as part of Phobos without
 special cases in the language for specific containers.
 



 is all cases and can result in identical asm I'd be willing to
 consider this.
 

 List!(Foo) list = new Array!(Foo); // instead of Foo[new]
 



 syntax.
 



 
 currently, AAs and arrays are implemented in the run-time. What I
 suggest is to move them to the stdlib. I don't see how such a move can
 impact performance which you're concerned with above.



// a is an array of ints

int b;
if(a.length > 5) b = a[5];
else b = a[$/2];

No runtime in that at all now.


 on the contrary,
 moving these types outside the runtime will make it easier to improve
 their implementations.
 
 regarding syntax, what's cleaner than calling an array an "Array"?
 T[new] is less clear and hackish.
 



if T[new] gets done as Array!T, what does T[] look like?

I'm not to worried about the fancy feature, it the bone simple stuff staying 
bone simple that I'm looking after.
Oct 19 2009
parent reply Yigal Chripun <yigal100 gmail.com> writes:
On 19/10/2009 22:53, BCS wrote:

 Hello Yigal,


 On 19/10/2009 19:10, BCS wrote:


 Hello Yigal,


 I think that Arrays and AAs need to be removed from the language. I
 prefer to have a collections framework as part of Phobos without
 special cases in the language for specific containers.



 is all cases and can result in identical asm I'd be willing to
 consider this.


 List!(Foo) list = new Array!(Foo); // instead of Foo[new]



 syntax.




 currently, AAs and arrays are implemented in the run-time. What I
 suggest is to move them to the stdlib. I don't see how such a move can
 impact performance which you're concerned with above.



 // a is an array of ints

 int b;
 if(a.length > 5) b = a[5];
 else b = a[$/2];

 No runtime in that at all now.



I don't see a reason why this can't be inlined by the compiler if Array 
is a lib type.

 on the contrary,
 moving these types outside the runtime will make it easier to improve
 their implementations.

 regarding syntax, what's cleaner than calling an array an "Array"?
 T[new] is less clear and hackish.



 if T[new] gets done as Array!T, what does T[] look like?




 I'm not to worried about the fancy feature, it the bone simple stuff
 staying bone simple that I'm looking after.
Oct 19 2009
parent BCS <none anon.com> writes:
Hello Yigal,


 On 19/10/2009 22:53, BCS wrote:
 

 int b;
 if(a.length > 5) b = a[5];
 else b = a[$/2];
 No runtime in that at all now.
 



 Array is a lib type.
 



Yes, it should inline. What I'm saying is that unless it is /guaranteed/ 
that it will /always/ inline, I'm going to have an issue.


 if T[new] gets done as Array!T, what does T[] look like?
 



 Phobos.
 



I think that T[] should be (at a minimum) the current slice semantics and 
implementation (the lvalue-length and ~/~= stuff is another question). If 
this happens to have the needed semantics to act as a range, all the better.

Having a clean, light construct to deal with low level memory access is just 
to handy to give it up completely.
Oct 19 2009