Ali Çehreli:

> >      int[] arr2 = [7, 8, 9]s;
> >      assert(is(typeof(arr2) == int[3]));
>
> That looks very confusing. The left-hand side looks like a slice, which I can append elements to but its type is a static array?

No, the type of the literal is of a fixed-side array, but it gets assigned to a dynamic array, so it's a slice. I am not sure but I Think arr2 data is allocated on the stack. It looks a little confusing, but I think it contains a rule we can learn.

Bye,
bearophile

Namespace:

> Your gig: https://github.com/D-Programming-Language/dmd/pull/2952#discussion_r8288045

My enhancement request was for the array[$] syntax. The idea of []s was invented by someone else (Timothee Cour?).

I like the practical comments by Hara. If Kenji thinks the []s is not useful for efficiency (because the efficiency can be obtained with just improvements of the compiler), then the []s syntax becomes less necessary.


On the other hand this is an interesting use case that compiler improvements alone could not be enough to allow:

void fun(int[3]) {}
void main() {
    int[3] x = [1, 2, 3];
    fun(x); // OK
    fun([1, 2, 3]); // error
    fun([1, 2, 3]s); // OK
}


Are vector ops supported?

int[6] a;
a = [1,2,3]s[] + [4,5,6]s[];

DIP34 is still a draft, and it shows, some corner cases are missing in that document and need to be found, fleshed out and added to the DIP34.

Bye,
bearophile

On Wed, Dec 11, 2013 at 5:17 PM, bearophile <bearophileHUGS@lycos.com>wrote:

> Namespace:
>
>  Your gig: https://github.com/D-Programming-Language/dmd/pull/
>> 2952#discussion_r8288045
>>
>
> My enhancement request was for the array[$] syntax. The idea of []s was invented by someone else (Timothee Cour?).
>
> I like the practical comments by Hara. If Kenji thinks the []s is not useful for efficiency (because the efficiency can be obtained with just improvements of the compiler), then the []s syntax becomes less necessary.
>
>
> On the other hand this is an interesting use case that compiler improvements alone could not be enough to allow:
>
> void fun(int[3]) {}
> void main() {
>     int[3] x = [1, 2, 3];
>     fun(x); // OK
>     fun([1, 2, 3]); // error
>     fun([1, 2, 3]s); // OK
> }
>

yes, that was the prime motivation for DIP34, being able to pass un-ambiguously a static array to a function without having to declare an intermediate variable first.

when fun() has overloads for both static and non-static arrays (or is just
declared as fun(T)(T a) ), the compiler cannot guess whether fun([1,2,3])
asks for static or dynamic array, and probably has to assume dynamic array.
And int[$] would require declaring a variable before passing it, eg:
int[$]x=[1,2,3].

With [1,2,3]s, there is no ambiguity.





>
>
> Are vector ops supported?
>
> int[6] a;
> a = [1,2,3]s[] + [4,5,6]s[];
>
> DIP34 is still a draft, and it shows, some corner cases are missing in that document and need to be found, fleshed out and added to the DIP34.
>
> Bye,
> bearophile
>

Timothee Cour:

>> void fun(int[3]) {}
>> void main() {
>>     int[3] x = [1, 2, 3];
>>     fun(x); // OK
>>     fun([1, 2, 3]); // error
>>     fun([1, 2, 3]s); // OK
>> }

Sorry, there's no error there.


> yes, that was the prime motivation for DIP34,

It seems Hara has received your message:
https://d.puremagic.com/issues/show_bug.cgi?id=8903#c7

Bye,
bearophile

I created a separate branch for the syntax Type[$] and auto[$]:
https://github.com/Dgame/dmd/commit/438a519d28d1683086083e673b2630a64c269f5f

Example:

----
int[$] arr_a1 = [54, 74, 90, 2010];
assert(is(typeof(arr_a1) == int[4]));
assert(arr_a1 == [54, 74, 90, 2010]);

int[$] arr_a2 = [2010, 90, 74, 54];
assert(is(typeof(arr_a2) == int[4]));
assert(arr_a2 == [2010, 90, 74, 54]);

int[] dyn_arr = [0, 1, 2, 3, 4, 5, 6, 7, 8, 9];
int[$] stat_arr = dyn_arr[3 .. 6];
assert(is(typeof(stat_arr) == int[3]));

auto[$] a_arr1 = [1, 2, 3];
assert(is(typeof(a_arr1) == int[3]));

auto[$] a_arr2 = dyn_arr[4 .. 8]; /// Sadly not possible for me

//int s = 2, e = 7;
//int[$] stat_arr2 = dyn_arr[s .. e]; /// fails

//int[$] stat_arr3 = dyn_arr[]; /// fails
----

Sadly I don't know how I could deduce the type of:
----
auto[$] a_arr2 = dyn_arr[4 .. 8]; /// Sadly not possible for me
----

I will try this again before I open a pull request. Maybe some of you know how to do this?

Namespace:

> Sadly I don't know how I could deduce the type of:
> ----
> auto[$] a_arr2 = dyn_arr[4 .. 8]; /// Sadly not possible for me

It seems a valid use case.

Bye,
bearophile

I presume the situation with this code is not changed by your patches:

string[3] a = ["red""green","blue"];
void main() {}

Bye,
bearophile

> string[3] a = ["red""green","blue"];
> void main() {}

I suggested to support such incomplete literals only with this extra syntax:

int[3] a = [1, 2, ...];
void main() {}

Bye,
bearophile

On 12/11/2013 05:09 PM, bearophile wrote:

> Ali Çehreli:
>
>> >      int[] arr2 = [7, 8, 9]s;
>> >      assert(is(typeof(arr2) == int[3]));
>>
>> That looks very confusing. The left-hand side looks like a slice,
>> which I can append elements to but its type is a static array?
>
> No, the type of the literal is of a fixed-side array, but it gets
> assigned to a dynamic array, so it's a slice.

No problem there.

> I am not sure but I Think
> arr2 data is allocated on the stack.

Although important, I wasn't considering that point at all.

> It looks a little confusing, but I
> think it contains a rule we can learn.

But look at the assertion: the type of the *slice* arr2 is int[3]. :)

>
> Bye,
> bearophile
>

Ali

Ali Çehreli:

> But look at the assertion: the type of the *slice* arr2 is int[3]. :)

I didn't notice that. It looks strange... I don't understand it.

Bye,
bearophile