On Wednesday, 20 September 2017 at 18:41:51 UTC, Timon Gehr wrote:
>> Can that be done without breakages? -- Andrei
>
> No.

Are thinking about

    typeof([1,2])

changing from

    int[]

to
    int[2]

?

On 9/20/17 1:33 PM, ag0aep6g wrote:
> On 09/20/2017 06:55 PM, Steven Schveighoffer wrote:
>> On 9/20/17 11:48 AM, Dgame wrote:
> [...]
>>> ----
>>> Unqual!T[n] s(T, size_t n)(T[n] arr)
>>> {
>>>      return arr;
>>> }
>>>
>>> auto a = "hallo".s;
>>> writeln(typeof(a).stringof); // char[5]
>>> ----
> [...]
>> Still it can't handle the case of:
>>
>> ubyte[3] x = [1, 2, 3];
> 
> Making the parameter variadic seems to do the trick:
> 
> ----
> import std.traits: Unqual;
> 
> Unqual!T[n] s(T, size_t n)(T[n] arr ...)
> {
>       return arr[];
>          /* With indirections, dmd would complain about an
>          escaping reference. Slicing shuts it up. */
> }
> 
> void main()
> {
>      auto a = s("hello");
>      static assert(is(typeof(a) == char[5]));
> 
>      auto x = s!ubyte(1, 2, 3);
>      static assert(is(typeof(x) == ubyte[3]));
> 
>      auto y = s(new int, new int);
>      static assert(is(typeof(y) == int*[2]));
> 
>      auto z = s(new immutable int, new immutable int);
>      static assert(is(typeof(z) == immutable(int)*[2]));
> }
> ----

I had no idea you could use static arrays for typesafe variadics! You learn something new every day :)

It's still a bit clunky. If you are explicitly specifying the type, you can't use an array literal, you must use the variadic form:

auto x1 = s("hello"); // x1 is char[5]
auto x2 = s!char("hello"); // T == char, but it fails?
auto x3 = s!char('h','e','l','l','o'); // works, but not pleasant.

I think when IFTI is given the type, it should still infer the size from the parameter.

This is close to a solution. I think if Jonathan's bug was fixed, we wouldn't even need the variadic form, though it could be useful as there's no way for the compiler to accidentally allocate on the heap. However, I still feel the compiler doing the work is a better choice. This is really basic initializer stuff, and generating templates for every call isn't always a good idea.

The slicing thing is ugly too... Doesn't that make an unnecessary copy?

-Steve

On 21.09.2017 12:33, Per Nordlöw wrote:
> On Wednesday, 20 September 2017 at 18:41:51 UTC, Timon Gehr wrote:
>>> Can that be done without breakages? -- Andrei
>>
>> No.
> 
> Are thinking about
> 
>      typeof([1,2])
> 
> changing from
> 
>      int[]
> 
> to
>      int[2]
> 
> ?

Yes, and everything that entails, for example:

auto x = [1,2];
x ~= 3; // goes from ok to `error: cannot append int to int[2]`.

On Wednesday, 20 September 2017 at 16:34:36 UTC, Andrei Alexandrescu wrote:
> On 09/20/2017 08:36 AM, jmh530 wrote:
>> On Wednesday, 20 September 2017 at 12:10:47 UTC, Andrei Alexandrescu wrote:
>>>
>>> How would this be useful? -- Andrei
>> 
>> Really just an additional convenience, instead of writing slice[0..$, 0..$, 0..$, i], you would write slice[.., .., .., i].
>
> The result looks pretty awful. We save two characters per dimension to get Morse code. -- Andrei

This is based on the Matlab colon operator. The .. was intended to keep it consistent with D's syntax.
https://www.mathworks.com/help/matlab/ref/colon.html

There was also a suggestion at mir-algorithm for allowing something like slice[0..2..$]
https://github.com/libmir/mir-algorithm/issues/53
Again, the same idea could be expressed with the colon operator.

On Thursday, 21 September 2017 at 13:58:14 UTC, Timon Gehr wrote:
> On 21.09.2017 12:33, Per Nordlöw wrote:
>> On Wednesday, 20 September 2017 at 18:41:51 UTC, Timon Gehr wrote:
>>>> Can that be done without breakages? -- Andrei
>>>
>>> No.
>> 
>> Are thinking about
>> 
>>      typeof([1,2])
>> 
>> changing from
>> 
>>      int[]
>> 
>> to
>>      int[2]
>> 
>> ?
>
> Yes, and everything that entails, for example:
>
> auto x = [1,2];
> x ~= 3; // goes from ok to `error: cannot append int to int[2]`.

Ok, breaks code, but I like it. Much better than the current behaviour.

On 9/22/17 3:55 AM, Dominikus Dittes Scherkl wrote:
> On Thursday, 21 September 2017 at 13:58:14 UTC, Timon Gehr wrote:
>> On 21.09.2017 12:33, Per Nordlöw wrote:
>>> On Wednesday, 20 September 2017 at 18:41:51 UTC, Timon Gehr wrote:
>>>>> Can that be done without breakages? -- Andrei
>>>>
>>>> No.
>>>
>>> Are thinking about
>>>
>>>      typeof([1,2])
>>>
>>> changing from
>>>
>>>      int[]
>>>
>>> to
>>>      int[2]
>>>
>>> ?
>>
>> Yes, and everything that entails, for example:
>>
>> auto x = [1,2];
>> x ~= 3; // goes from ok to `error: cannot append int to int[2]`.
> 
> Ok, breaks code, but I like it. Much better than the current behaviour.

Don't fall in love with it. It's not going to happen, as this would be too much breakage for almost no gain.

Much as I want a way to statically infer a static array size, this is not the answer.

-Steve

On Friday, September 22, 2017 08:19:32 Steven Schveighoffer via Digitalmars- d wrote:
> On 9/22/17 3:55 AM, Dominikus Dittes Scherkl wrote:
> > On Thursday, 21 September 2017 at 13:58:14 UTC, Timon Gehr wrote:
> >> On 21.09.2017 12:33, Per Nordlöw wrote:
> >>> On Wednesday, 20 September 2017 at 18:41:51 UTC, Timon Gehr wrote:
> >>>>> Can that be done without breakages? -- Andrei
> >>>>
> >>>> No.
> >>>
> >>> Are thinking about
> >>>
> >>>      typeof([1,2])
> >>>
> >>> changing from
> >>>
> >>>      int[]
> >>>
> >>> to
> >>>      int[2]
> >>>
> >>> ?
> >>
> >> Yes, and everything that entails, for example:
> >>
> >> auto x = [1,2];
> >> x ~= 3; // goes from ok to `error: cannot append int to int[2]`.
> >
> > Ok, breaks code, but I like it. Much better than the current behaviour.
>
> Don't fall in love with it. It's not going to happen, as this would be too much breakage for almost no gain.
>
> Much as I want a way to statically infer a static array size, this is not the answer.

It would also interact horribly with range-based functions. I honestly don't see any benefit to making array literals be static arrays by default except for the fact that you'd then get size inference, and there are better ways to add that to the language if we want to do that.

- Jonathan M Davis