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