October 20, 2009
On 20/10/2009 03:50, Walter Bright wrote:
> Currently, static arrays are (as in C) half-value types and
> half-reference types. This tends to cause a series of weird problems and
> special cases in the language semantics, such as functions not being
> able to return static arrays, and out parameters not being possible to
> be static arrays.
>
> Andrei and I agonized over this for some time, and eventually came to
> the conclusion that static arrays should become value types. I.e.,
>
> T[3]
>
> should behave much as if it were:
>
> struct ??
> {
> T[3];
> }
>
> Then it can be returned from a function. In particular,
>
> void foo(T[3] a)
>
> is currently done (as in C) by passing a pointer to the array, and then
> with a bit of compiler magic 'a' is rewritten as (*a)[3]. Making this
> change would mean that the entire array would be pushed onto the
> parameter stack, i.e. a copy of the array, rather than a reference to it.
>
> Making this change would clean up the internal behavior of types.
> They'll be more orthogonal and consistent, and templates will work better.
>
> The previous behavior for function parameters can be retained by making
> it a ref parameter:
>
> void foo(ref T[3] a)

that's good news :)
October 20, 2009
Walter Bright wrote:
> Currently, static arrays are (as in C) half-value types and half-reference types. This tends to cause a series of weird problems and special cases in the language semantics, such as functions not being able to return static arrays, and out parameters not being possible to be static arrays.
> 
> Andrei and I agonized over this for some time, and eventually came to the conclusion that static arrays should become value types. I.e.,
> 
>   T[3]
> 
> should behave much as if it were:
> 
>   struct ??
>   {
>      T[3];
>   }
> 
> Then it can be returned from a function. In particular,
> 
>   void foo(T[3] a)
> 
> is currently done (as in C) by passing a pointer to the array, and then with a bit of compiler magic 'a' is rewritten as (*a)[3]. Making this change would mean that the entire array would be pushed onto the parameter stack, i.e. a copy of the array, rather than a reference to it.
> 
> Making this change would clean up the internal behavior of types. They'll be more orthogonal and consistent, and templates will work better.
> 
> The previous behavior for function parameters can be retained by making it a ref parameter:
> 
>    void foo(ref T[3] a)

I think this change is mandatory. We need it for SIMD operations. It will allow us to implement efficient vectors.
October 20, 2009
Walter Bright wrote:
> Currently, static arrays are (as in C) half-value types and half-reference types. This tends to cause a series of weird problems and special cases in the language semantics, such as functions not being able to return static arrays, and out parameters not being possible to be static arrays.
> 
> Andrei and I agonized over this for some time, and eventually came to the conclusion that static arrays should become value types. I.e.,
> 
>   T[3]
> 
> should behave much as if it were:
> 
>   struct ??
>   {
>      T[3];
>   }
> 
> Then it can be returned from a function. In particular,
> 
>   void foo(T[3] a)
> 
> is currently done (as in C) by passing a pointer to the array, and then with a bit of compiler magic 'a' is rewritten as (*a)[3]. Making this change would mean that the entire array would be pushed onto the parameter stack, i.e. a copy of the array, rather than a reference to it.
> 
> Making this change would clean up the internal behavior of types. They'll be more orthogonal and consistent, and templates will work better.
> 
> The previous behavior for function parameters can be retained by making it a ref parameter:
> 
>    void foo(ref T[3] a)

I don't know why people are agreeing about this. At least I don't understand what the problem is with static arrays. You say:

"Currently, static arrays are (as in C) half-value types and half-reference types. This tends to cause a series of weird problems and special cases in the language semantics, such as functions not being able to return static arrays, and out parameters not being possible to be static arrays."

But WHY??? What's the specific problem? I understand that passing things by value would solve this, but will hurt performance and it's not in sync with "arrays are passed by reference".
October 20, 2009
Don:

>I think this change is mandatory. We need it for SIMD operations.<

Why? Why the compiler can't optimize things and perform SIMD operations with the fixed-sized array semantics of D1? (I ask this for LDC too, that's mostly D1 still).

Bye,
bearophile
October 20, 2009
bearophile wrote:
> Don:
> 
>> I think this change is mandatory. We need it for SIMD operations.<
> 
> Why? Why the compiler can't optimize things and perform SIMD operations with the fixed-sized array semantics of D1? (I ask this for LDC too, that's mostly D1 still).
> 
> Bye,
> bearophile
Because they are passed by reference. It certainly can't do it on D1:

float dot(float[4] x) {
   x[3] = 4.5; // surprise!
   return 0;
}

void main()
{
  float[4] a;
  a[3]= 0;
  float x = dot(a);
  assert(a[3]==0); // FAILS!
}
October 20, 2009
On Mon, 19 Oct 2009 18:50:46 -0700, Walter Bright <newshound1@digitalmars.com> wrote:

>Currently, static arrays are (as in C) half-value types and half-reference types. This tends to cause a series of weird problems and special cases in the language semantics, such as functions not being able to return static arrays, and out parameters not being possible to be static arrays.
>
>Andrei and I agonized over this for some time, and eventually came to the conclusion that static arrays should become value types. I.e.,
>
>   T[3]
>
>should behave much as if it were:
>
>   struct ??
>   {
>      T[3];
>   }
>
>Then it can be returned from a function. In particular,
>
>   void foo(T[3] a)
>
>is currently done (as in C) by passing a pointer to the array, and then with a bit of compiler magic 'a' is rewritten as (*a)[3]. Making this change would mean that the entire array would be pushed onto the parameter stack, i.e. a copy of the array, rather than a reference to it.
>
>Making this change would clean up the internal behavior of types. They'll be more orthogonal and consistent, and templates will work better.
>
>The previous behavior for function parameters can be retained by making it a ref parameter:
>
>    void foo(ref T[3] a)

Hooah!

I guess their .init value won't be fixed to be consistent with other types?
October 20, 2009
dsimcha, el 20 de octubre a las 02:44 me escribiste:
> == Quote from Walter Bright (newshound1@digitalmars.com)'s article
> > Currently, static arrays are (as in C) half-value types and
> > half-reference types. This tends to cause a series of weird problems and
> > special cases in the language semantics, such as functions not being
> > able to return static arrays, and out parameters not being possible to
> > be static arrays.
> > Andrei and I agonized over this for some time, and eventually came to
> > the conclusion that static arrays should become value types. I.e.,
> >    T[3]
> > should behave much as if it were:
> >    struct ??
> >    {
> >       T[3];
> >    }
> > Then it can be returned from a function. In particular,
> >    void foo(T[3] a)
> > is currently done (as in C) by passing a pointer to the array, and then
> > with a bit of compiler magic 'a' is rewritten as (*a)[3]. Making this
> > change would mean that the entire array would be pushed onto the
> > parameter stack, i.e. a copy of the array, rather than a reference to it.
> > Making this change would clean up the internal behavior of types.
> > They'll be more orthogonal and consistent, and templates will work better.
> > The previous behavior for function parameters can be retained by making
> > it a ref parameter:
> >     void foo(ref T[3] a)
> 
> Vote++.  It's funny, I use static arrays so little that I never realized that they weren't passed by value to functions.  I'd absolutely love to be able to just return static arrays from functions, and often use structs to do that now, but using structs feels like a really ugly hack.

It would be the poor men tuple for returning (homogeneous) stuff =P

-- 
Leandro Lucarella (AKA luca)                     http://llucax.com.ar/
----------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------
La máquina de la moneda, mirá como te queda!
	-- Sidharta Kiwi
October 20, 2009
Tue, 20 Oct 2009 10:34:35 -0300, Leandro Lucarella thusly wrote:

> dsimcha, el 20 de octubre a las 02:44 me escribiste:
>> == Quote from Walter Bright (newshound1@digitalmars.com)'s article
>> > Currently, static arrays are (as in C) half-value types and
>> > half-reference types. This tends to cause a series of weird problems
>> > and special cases in the language semantics, such as functions not
>> > being able to return static arrays, and out parameters not being
>> > possible to be static arrays.
>> > Andrei and I agonized over this for some time, and eventually came to
>> > the conclusion that static arrays should become value types. I.e.,
>> >    T[3]
>> > should behave much as if it were:
>> >    struct ??
>> >    {
>> >       T[3];
>> >    }
>> > Then it can be returned from a function. In particular,
>> >    void foo(T[3] a)
>> > is currently done (as in C) by passing a pointer to the array, and
>> > then with a bit of compiler magic 'a' is rewritten as (*a)[3]. Making
>> > this change would mean that the entire array would be pushed onto the
>> > parameter stack, i.e. a copy of the array, rather than a reference to
>> > it. Making this change would clean up the internal behavior of types.
>> > They'll be more orthogonal and consistent, and templates will work
>> > better. The previous behavior for function parameters can be retained
>> > by making it a ref parameter:
>> >     void foo(ref T[3] a)
>> 
>> Vote++.  It's funny, I use static arrays so little that I never realized that they weren't passed by value to functions.  I'd absolutely love to be able to just return static arrays from functions, and often use structs to do that now, but using structs feels like a really ugly hack.
> 
> It would be the poor men tuple for returning (homogeneous) stuff =P

It depends on how you define things. Traditionally tuples are seen as a generalization of pairs (2 elements -> n elements). Records, on the other hand, are generalization of tuples (simple number index -> named elements). You need couple of additional layers of generalization to come up with structs (subtyping, member functions, generics etc.)

One nasty thing about D's structs is that they don't have structural equivalence relation unlike tuples. So you need to use the same container struct type to get the same semantics. To achieve that you would need some kind of STuple on standard library level or other kinds of hacks.

What I find unfortunate in D is that your abstractions come in two sizes - either you use the modest tiny construct that does not scale elegantly or the enormous hammer to crush things down theatretically.
October 20, 2009
language_fan, el 20 de octubre a las 13:52 me escribiste:
> Tue, 20 Oct 2009 10:34:35 -0300, Leandro Lucarella thusly wrote:
> 
> > dsimcha, el 20 de octubre a las 02:44 me escribiste:
> >> == Quote from Walter Bright (newshound1@digitalmars.com)'s article
> >> > Currently, static arrays are (as in C) half-value types and
> >> > half-reference types. This tends to cause a series of weird problems
> >> > and special cases in the language semantics, such as functions not
> >> > being able to return static arrays, and out parameters not being
> >> > possible to be static arrays.
> >> > Andrei and I agonized over this for some time, and eventually came to
> >> > the conclusion that static arrays should become value types. I.e.,
> >> >    T[3]
> >> > should behave much as if it were:
> >> >    struct ??
> >> >    {
> >> >       T[3];
> >> >    }
> >> > Then it can be returned from a function. In particular,
> >> >    void foo(T[3] a)
> >> > is currently done (as in C) by passing a pointer to the array, and
> >> > then with a bit of compiler magic 'a' is rewritten as (*a)[3]. Making
> >> > this change would mean that the entire array would be pushed onto the
> >> > parameter stack, i.e. a copy of the array, rather than a reference to
> >> > it. Making this change would clean up the internal behavior of types.
> >> > They'll be more orthogonal and consistent, and templates will work
> >> > better. The previous behavior for function parameters can be retained
> >> > by making it a ref parameter:
> >> >     void foo(ref T[3] a)
> >> 
> >> Vote++.  It's funny, I use static arrays so little that I never realized that they weren't passed by value to functions.  I'd absolutely love to be able to just return static arrays from functions, and often use structs to do that now, but using structs feels like a really ugly hack.
> > 
> > It would be the poor men tuple for returning (homogeneous) stuff =P
> 
> It depends on how you define things. Traditionally tuples are seen as a generalization of pairs (2 elements -> n elements). Records, on the other

In what tradition? C++ maybe. I never saw a pair type outside C++, but saw tuples everywhere (even in other structured languages like SQL).

> hand, are generalization of tuples (simple number index -> named elements). You need couple of additional layers of generalization to come up with structs (subtyping, member functions, generics etc.)
> 
> One nasty thing about D's structs is that they don't have structural equivalence relation unlike tuples. So you need to use the same container struct type to get the same semantics. To achieve that you would need some kind of STuple on standard library level or other kinds of hacks.
> 
> What I find unfortunate in D is that your abstractions come in two sizes - either you use the modest tiny construct that does not scale elegantly or the enormous hammer to crush things down theatretically.

I don't understand very well what are you saying anyways...

-- 
Leandro Lucarella (AKA luca)                     http://llucax.com.ar/
----------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------
Fantasy is as important as wisdom
October 20, 2009
On Mon, 19 Oct 2009 21:50:46 -0400, Walter Bright <newshound1@digitalmars.com> wrote:

> Currently, static arrays are (as in C) half-value types and half-reference types. This tends to cause a series of weird problems and special cases in the language semantics, such as functions not being able to return static arrays, and out parameters not being possible to be static arrays.
>
> Andrei and I agonized over this for some time, and eventually came to the conclusion that static arrays should become value types. I.e.,
>
>    T[3]
>
> should behave much as if it were:
>
>    struct ??
>    {
>       T[3];
>    }
>
> Then it can be returned from a function. In particular,
>
>    void foo(T[3] a)
>
> is currently done (as in C) by passing a pointer to the array, and then with a bit of compiler magic 'a' is rewritten as (*a)[3]. Making this change would mean that the entire array would be pushed onto the parameter stack, i.e. a copy of the array, rather than a reference to it.
>
> Making this change would clean up the internal behavior of types. They'll be more orthogonal and consistent, and templates will work better.
>
> The previous behavior for function parameters can be retained by making it a ref parameter:
>
>     void foo(ref T[3] a)

What happens for IFTI?

void foo(T)(T t)
{
   return t[2];
}

void main()
{
   int[3] x;
   x[] = 5;
   printf(foo(x));
}

I would think T would resolve to int[3], which means pass by value.  You'd need a specialization for static arrays to get the current behavior.

Don't get me wrong, I would love to see static arrays become real types, but I wonder if there are any ways we can "optimize out" the staticness of an array argument for templates.  In particular, I hate how IFTI likes to assume static array for literals...

In the absence of such an optimization, I'd still prefer static arrays become value types like you say.

-Steve