The subject pretty much says it all.

If I have a function:
void function(int[] arr);

I'd like to be able to call it with:

int[12] a;
function(a);

I know I can do:
function(a[]);

It just seems like extra unneeded superfluous unnecessary redundancy. I don't see any static typing protection/errors prevented from doing this.

Shachar

Shachar Shemesh:

> The subject pretty much says it all.
>
> If I have a function:
> void function(int[] arr);
>
> I'd like to be able to call it with:
>
> int[12] a;
> function(a);
>
> I know I can do:
> function(a[]);
>
> It just seems like extra unneeded superfluous unnecessary redundancy. I don't see any static typing protection/errors prevented from doing this.

Currently it works:


void foo(int[] arr) {}
void main() {
    int[12] a;
    foo(a);
}


Bye,
bearophile

On Wednesday, 17 December 2014 at 13:13:43 UTC, Shachar Shemesh wrote:
> It just seems like extra unneeded superfluous unnecessary redundancy.

It is somewhat important because storing a slice to a static array is a big problem:

int[] stored;
void func(int[] s) {
   stored = s;
}

void test() {
  int[12] a;
  func(a);
}

void main() {
   test();
   stored[] = 0; // just overwritten the stack!
}



Making you write the [] doesn't prevent this case, but it does at least remind you that a static array and a dynamic array aren't completely the same - it gives you a chance to look up the docs for func() and figure if it does store, dup it.


Though like bearophile said, the compiler DOES allow this implicit conversion at times, which has caused my bugs before. It is especially nasty when a char[x] gets implicitly converted to string due to this combining with the pure function -> immutable thing! There's a function in phobos that will convert like that and cause hidden crashes. Nasty.

Adam D. Ruppe:

> the compiler DOES allow this implicit conversion at times, which has caused my bugs before.

We will hopefully have some simplified kind of tracking of memory ownership to remove this problem.

Bye,
bearophile

On 17/12/14 17:02, Adam D. Ruppe wrote:
> On Wednesday, 17 December 2014 at 13:13:43 UTC, Shachar Shemesh wrote:
>> It just seems like extra unneeded superfluous unnecessary redundancy.
>
> It is somewhat important because storing a slice to a static array is a
> big problem:
>

Any time you pass by reference a reference to a stack allocated variable, this problem is there. I don't see how arrays are any different.

What's more, this is precisely why @safe and friends exist (and, if memory serves me right, D actually catches and warns about the use case you described).

Shachar

On Friday, December 19, 2014 09:47:43 Shachar Shemesh via Digitalmars-d wrote:
> On 17/12/14 17:02, Adam D. Ruppe wrote:
> > On Wednesday, 17 December 2014 at 13:13:43 UTC, Shachar Shemesh wrote:
> >> It just seems like extra unneeded superfluous unnecessary redundancy.
> >
> > It is somewhat important because storing a slice to a static array is a big problem:
> >
>
> Any time you pass by reference a reference to a stack allocated
> variable, this problem is there. I don't see how arrays are any different.
>
> What's more, this is precisely why @safe and friends exist (and, if memory serves me right, D actually catches and warns about the use case you described).

D catches taking the address of a local variable, but it unfortunately does not currently catch slicing a static array. Regardless, IMHO slicing a static array should be treated entirely like taking the address of a variable and not only be considered unsafe but be required to be explicit. While implicit slicing of static arrays is occasionally nice, it's definitely a source of nasty bugs, and personally, I think that it was a mistake to ever have it anywhere in the language.

- Jonathan M Davis