On Wednesday, 11 December 2013 at 04:01:11 UTC, Ali Çehreli wrote:
> On 12/10/2013 04:37 PM, Namespace wrote:
>
> >      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?
>
> Ali

That is intended (but can be discussed of course). It was often desired to write int[$] arr = [1, 2, 3]; to auto-determine the dimension. And my change does something like that: if you assign a static array to a slice, the dimension is auto-determined and the type is adapted.

On Wednesday, 11 December 2013 at 09:49:13 UTC, Namespace wrote:
> On Wednesday, 11 December 2013 at 04:01:11 UTC, Ali Çehreli wrote:
>> On 12/10/2013 04:37 PM, Namespace wrote:
>>
>> >     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?
>>
>> Ali
>
> That is intended (but can be discussed of course). It was often desired to write int[$] arr = [1, 2, 3]; to auto-determine the dimension. And my change does something like that: if you assign a static array to a slice, the dimension is auto-determined and the type is adapted.

I agree with Ali. arr2 says it's a dynamic array but it's not. This could easily lead to errors worse than the class caused by implicit conversions (what's worse than explicitly saying you want an x but getting a y instead?). `int[$]` for this purpose would be acceptable, however. I actually like that idea, personally.

On Wednesday, 11 December 2013 at 16:28:39 UTC, Chris Cain wrote:
> On Wednesday, 11 December 2013 at 09:49:13 UTC, Namespace wrote:
>> On Wednesday, 11 December 2013 at 04:01:11 UTC, Ali Çehreli wrote:
>>> On 12/10/2013 04:37 PM, Namespace wrote:
>>>
>>> >    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?
>>>
>>> Ali
>>
>> That is intended (but can be discussed of course). It was often desired to write int[$] arr = [1, 2, 3]; to auto-determine the dimension. And my change does something like that: if you assign a static array to a slice, the dimension is auto-determined and the type is adapted.
>
> I agree with Ali. arr2 says it's a dynamic array but it's not. This could easily lead to errors worse than the class caused by implicit conversions (what's worse than explicitly saying you want an x but getting a y instead?). `int[$]` for this purpose would be acceptable, however. I actually like that idea, personally.

Ok, I will change that. ;)
And I will try to implement the syntax for int[$].

On Wednesday, 11 December 2013 at 18:31:20 UTC, Namespace wrote:
> On Wednesday, 11 December 2013 at 16:28:39 UTC, Chris Cain wrote:
>> On Wednesday, 11 December 2013 at 09:49:13 UTC, Namespace wrote:
>>> On Wednesday, 11 December 2013 at 04:01:11 UTC, Ali Çehreli wrote:
>>>> On 12/10/2013 04:37 PM, Namespace wrote:
>>>>
>>>> >   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?
>>>>
>>>> Ali
>>>
>>> That is intended (but can be discussed of course). It was often desired to write int[$] arr = [1, 2, 3]; to auto-determine the dimension. And my change does something like that: if you assign a static array to a slice, the dimension is auto-determined and the type is adapted.
>>
>> I agree with Ali. arr2 says it's a dynamic array but it's not. This could easily lead to errors worse than the class caused by implicit conversions (what's worse than explicitly saying you want an x but getting a y instead?). `int[$]` for this purpose would be acceptable, however. I actually like that idea, personally.
>
> Ok, I will change that. ;)
> And I will try to implement the syntax for int[$].

Was a bit tricky but it works now (even if it may not be perfect):
https://github.com/Dgame/dmd/commits/static_array_literals

Example:

----
import std.stdio;

void foo(int[3] arr) {
	assert(is(typeof(arr) == int[3]));
}

void bar(T)(T arr) {
	assert(is(T == int[3]));
}

void quatz(int[] arr) {
	assert(is(typeof(arr) == int[]));
}

void main() {
	int[] arr0 = [1, 2, 3];
	assert(is(typeof(arr0) == int[]));
	assert(arr0 == [1, 2, 3]);

	int[3] arr1 = [4, 5, 6]s;
	assert(is(typeof(arr1) == int[3]));
	assert(arr1 == [4, 5, 6]);

	int[] arr2 = [7, 8, 9]s;
	assert(is(typeof(arr2) == int[/*3*/]));
	assert(arr2 == [7, 8, 9]);

	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]s;
	assert(is(typeof(arr_a2) == int[4]));
	assert(arr_a2 == [2010, 90, 74, 54]);

	foo([1, 2, 3]);
	foo([4, 5, 6]s);

	bar([44, 55, 66]s);

	auto arr3 = [111, 222, 333];
	assert(is(typeof(arr3) == int[]));

	auto arr4 = [444, 555, 666]s;
	assert(is(typeof(arr4) == int[3]));

	quatz([3, 2, 1]);
	quatz([8, 7, 6]s);
}
----

Namespace:

> void main() {
> 	int[] arr0 = [1, 2, 3];
> 	assert(is(typeof(arr0) == int[]));
> 	assert(arr0 == [1, 2, 3]);
>
> 	int[3] arr1 = [4, 5, 6]s;
> 	assert(is(typeof(arr1) == int[3]));
> 	assert(arr1 == [4, 5, 6]);
>
> 	int[] arr2 = [7, 8, 9]s;
> 	assert(is(typeof(arr2) == int[/*3*/]));
> 	assert(arr2 == [7, 8, 9]);
>
> 	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]s;
> 	assert(is(typeof(arr_a2) == int[4]));
> 	assert(arr_a2 == [2010, 90, 74, 54]);
>
> 	foo([1, 2, 3]);
> 	foo([4, 5, 6]s);
>
> 	bar([44, 55, 66]s);
>
> 	auto arr3 = [111, 222, 333];
> 	assert(is(typeof(arr3) == int[]));
>
> 	auto arr4 = [444, 555, 666]s;
> 	assert(is(typeof(arr4) == int[3]));
>
> 	quatz([3, 2, 1]);
> 	quatz([8, 7, 6]s);
> }

Very good, this seems a step forward for D. Are you going to create two pull requests for dmd? (it will not be accepted before dmd 2.066).

Is it also guarding against this?
http://d.puremagic.com/issues/show_bug.cgi?id=3849

That in short is this mistake (this currently doesn't give errors):

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

Bye,
bearophile

On Wednesday, 11 December 2013 at 19:51:24 UTC, bearophile wrote:
> Namespace:
>
>> void main() {
>> 	int[] arr0 = [1, 2, 3];
>> 	assert(is(typeof(arr0) == int[]));
>> 	assert(arr0 == [1, 2, 3]);
>>
>> 	int[3] arr1 = [4, 5, 6]s;
>> 	assert(is(typeof(arr1) == int[3]));
>> 	assert(arr1 == [4, 5, 6]);
>>
>> 	int[] arr2 = [7, 8, 9]s;
>> 	assert(is(typeof(arr2) == int[/*3*/]));
>> 	assert(arr2 == [7, 8, 9]);
>>
>> 	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]s;
>> 	assert(is(typeof(arr_a2) == int[4]));
>> 	assert(arr_a2 == [2010, 90, 74, 54]);
>>
>> 	foo([1, 2, 3]);
>> 	foo([4, 5, 6]s);
>>
>> 	bar([44, 55, 66]s);
>>
>> 	auto arr3 = [111, 222, 333];
>> 	assert(is(typeof(arr3) == int[]));
>>
>> 	auto arr4 = [444, 555, 666]s;
>> 	assert(is(typeof(arr4) == int[3]));
>>
>> 	quatz([3, 2, 1]);
>> 	quatz([8, 7, 6]s);
>> }
>
> Very good, this seems a step forward for D. Are you going to create two pull requests for dmd? (it will not be accepted before dmd 2.066).

I'm unsure. I'm not that familiar with dmd at all, so maybe some more advanced guy like Kenji should review my code and create an own, better pull. What do you mean?

>
> Is it also guarding against this?
> http://d.puremagic.com/issues/show_bug.cgi?id=3849
>
> That in short is this mistake (this currently doesn't give errors):
>
> string[3] a = ["red""green","blue"];
> void main() {}
>
> Bye,
> bearophile

Not yet tested, but I will. :)

Namespace:

> I'm unsure. I'm not that familiar with dmd at all, so maybe some more advanced guy like Kenji should review my code and create an own, better pull.

In that code there is both the [$] and the []s syntaxes. So it's better to submit them as two separated pull requests for the D front-end.

Lately Kenji seems a little less active, but he will probably be glad to review your code, fix it, etc.


> What do you mean?

Walter said that dmd 2.065 is meant only as bug-fix release (expecially ICEs) so no "significant" language enhancement requests will be added in dmd 2.065, and they have to wait for dmd 2.066. But dmd 2.065 is supposed to end quicker, so we will not wait a lot of time.


> Not yet tested, but I will. :)

(Issue 3849 also suggests the "..." syntax inside array literals to fulfill a narrow corner case that Walter seems to appreciate. I think it's not an important syntax.)

Bye,
bearophile

On Wednesday, 11 December 2013 at 20:50:01 UTC, bearophile wrote:
> Namespace:
>
>> I'm unsure. I'm not that familiar with dmd at all, so maybe some more advanced guy like Kenji should review my code and create an own, better pull.
>
> In that code there is both the [$] and the []s syntaxes. So it's better to submit them as two separated pull requests for the D front-end.
>
> Lately Kenji seems a little less active, but he will probably be glad to review your code, fix it, etc.
>
>
>> What do you mean?
>
> Walter said that dmd 2.065 is meant only as bug-fix release (expecially ICEs) so no "significant" language enhancement requests will be added in dmd 2.065, and they have to wait for dmd 2.066. But dmd 2.065 is supposed to end quicker, so we will not wait a lot of time.
>
>
>> Not yet tested, but I will. :)
>
> (Issue 3849 also suggests the "..." syntax inside array literals to fulfill a narrow corner case that Walter seems to appreciate. I think it's not an important syntax.)
>
> Bye,
> bearophile

I'm pretty nervous, but here is the first: https://github.com/D-Programming-Language/dmd/pull/2952

Namespace:

> I'm pretty nervous, but here is the first: https://github.com/D-Programming-Language/dmd/pull/2952

Good. Keep in mind that at best it will take a month or more for your patch to be accepted. Also patches that implement basic language features like this pass a stringent process of review, that can be laborious and a bit painful. And even after after all that work there's a certain probability of rejection. So you have to build stamina and accumulate patience :-) (Other kind of patches, like D front-end bug fixes or Phobos improvements are faster and often much less painful).

Bye,
bearophile

On Wednesday, 11 December 2013 at 23:20:30 UTC, bearophile wrote:
> Namespace:
>
>> I'm pretty nervous, but here is the first: https://github.com/D-Programming-Language/dmd/pull/2952
>
> Good. Keep in mind that at best it will take a month or more for your patch to be accepted. Also patches that implement basic language features like this pass a stringent process of review, that can be laborious and a bit painful. And even after after all that work there's a certain probability of rejection. So you have to build stamina and accumulate patience :-) (Other kind of patches, like D front-end bug fixes or Phobos improvements are faster and often much less painful).
>
> Bye,
> bearophile

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