www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - new T[10] => new T[](10)

reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Now with the full legitimization of statically-sized array, the 
syntactic kludge "new T[10]" is more painful than ever.

Walter and I were talking about changing the semantics of "new T[10]" to 
mean "allocate a T[10] object and give me a pointer to it" and make the 
syntax "new T[](10)" mean "allocate an array of 10 elements and give me 
a handle to it."

I see major disruptions of existing code though. Do you guys have ideas 
of a clean migration path?


Andrei
Feb 14 2010
next sibling parent reply dsimcha <dsimcha yahoo.com> writes:
== Quote from Andrei Alexandrescu (SeeWebsiteForEmail erdani.org)'s article
 Now with the full legitimization of statically-sized array, the
 syntactic kludge "new T[10]" is more painful than ever.
 Walter and I were talking about changing the semantics of "new T[10]" to
 mean "allocate a T[10] object and give me a pointer to it" and make the
 syntax "new T[](10)" mean "allocate an array of 10 elements and give me
 a handle to it."
 I see major disruptions of existing code though. Do you guys have ideas
 of a clean migration path?
 Andrei

I'd recommend a simple compiler switch where new T[10] doesn't compile. You turn this on when you're porting old code. When your old code compiles with this switch on, you know it doesn't have any legacy "new T[10]" stuff in it. You can then turn this switch off and start using the new meaning of "new T[10]" if you want. Also, although I don't care about the breaking of old code (D2 is still alpha and warts should be fixed no matter how much it hurts backwards compatibility), I don't see what advantage this more verbose syntax offers. Why would anyone ever want to allocate a statically sized array on the heap? In these cases, what's wrong with just using a dynamic array?
Feb 14 2010
parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Sun, 14 Feb 2010 17:09:46 -0500, dsimcha <dsimcha yahoo.com> wrote:

 == Quote from Andrei Alexandrescu (SeeWebsiteForEmail erdani.org)'s  
 article
 Now with the full legitimization of statically-sized array, the
 syntactic kludge "new T[10]" is more painful than ever.
 Walter and I were talking about changing the semantics of "new T[10]" to
 mean "allocate a T[10] object and give me a pointer to it" and make the
 syntax "new T[](10)" mean "allocate an array of 10 elements and give me
 a handle to it."
 I see major disruptions of existing code though. Do you guys have ideas
 of a clean migration path?
 Andrei

I'd recommend a simple compiler switch where new T[10] doesn't compile. You turn this on when you're porting old code. When your old code compiles with this switch on, you know it doesn't have any legacy "new T[10]" stuff in it. You can then turn this switch off and start using the new meaning of "new T[10]" if you want. Also, although I don't care about the breaking of old code (D2 is still alpha and warts should be fixed no matter how much it hurts backwards compatibility), I don't see what advantage this more verbose syntax offers. Why would anyone ever want to allocate a statically sized array on the heap? In these cases, what's wrong with just using a dynamic array?

A dynamic array consists of 2 elements, a length and a pointer. If you never change the length, that's a lot of wasted bytes and passing around of data if you never change it. Also, the current interpretation makes generic code more difficult. It makes statically sized arrays different than all other value types. Just for that reason, it's worth the change. If you're going to make the argument that new int[x] is a dynamic array, then I'd argue that new int[x][y][z] should not have any static arrays anywhere. Having new int[x][y][z] make only the z dimension a dynamic array is madness. I think the proposed fix is the most sane and consistent possible. -Steve
Feb 15 2010
prev sibling next sibling parent BCS <none anon.com> writes:
Hello Andrei,

 Now with the full legitimization of statically-sized array, the
 syntactic kludge "new T[10]" is more painful than ever.
 
 Walter and I were talking about changing the semantics of "new T[10]"
 to mean "allocate a T[10] object and give me a pointer to it" and make
 the syntax "new T[](10)" mean "allocate an array of 10 elements and
 give me a handle to it."
 
 I see major disruptions of existing code though. Do you guys have
 ideas of a clean migration path?
 

I'm not seeing a problem. given: new T[exp] If exp is not a compile time constant, return a dynamic-sized array of the runtime evaluated value. else return a statically-sized array that can be implicitly converted to a dynamic-sized array. The only problem I see is: how would this interact with CTFE? -- <IXOYE><
Feb 14 2010
prev sibling parent Stewart Gordon <smjg_1998 yahoo.com> writes:
Andrei Alexandrescu wrote:
<snip>
 I see major disruptions of existing code though. Do you guys have ideas 
 of a clean migration path?

Make "new T[10]" a doubly-typed expression. T[] or T[10]* depending on what you try to do with it. But which should be the default type? Stewart.
Feb 15 2010