On Wednesday, 20 September 2017 at 12:41:57 UTC, Stefan Koch wrote:
> On Wednesday, 20 September 2017 at 12:08:45 UTC, Andrei Alexandrescu wrote:
>> On 09/20/2017 07:49 AM, Jonathan M Davis wrote:
>>> On Wednesday, September 20, 2017 10:59:56 Per Nordlöw via Digitalmars-d
>>> wrote:
>>>> On Wednesday, 20 September 2017 at 09:13:52 UTC, Jonathan M Davis
>>>>
>>>> wrote:
>>>>> https://issues.dlang.org/show_bug.cgi?id=12625
>>>>>
>>>>> - Jonathan M Davis
>>>>
>>>> Looks like we should we wait for
>>>> https://github.com/dlang/dmd/pull/7110 to be merged before adding
>>>> `s` to druntime.
>>> 
>>> It also should have a much more descriptive name (e.g. staticArray, though
>>> maybe that's a bit long), and I think that std.array really does make more
>>> sense than object.d. object.d is for stuff that's essentially built-in, not
>>> for helper functions.
>>
>> Agreed. Also: the length of the name should not be a problem, this is not a frequently used facility. -- Andrei
>
> I do strongly disagree with this approach, rather we should type array literals as static arrays by default and rely on implicit conversion to slices.

A long time ago I believe this was the case, but it was changed because it caused a lot of problems. What they were I don't know.

On Wednesday, September 20, 2017 12:59:02 Meta via Digitalmars-d wrote:
> On Wednesday, 20 September 2017 at 12:41:57 UTC, Stefan Koch
>
> wrote:
> > On Wednesday, 20 September 2017 at 12:08:45 UTC, Andrei
> >
> > Alexandrescu wrote:
> >> On 09/20/2017 07:49 AM, Jonathan M Davis wrote:
> >>> On Wednesday, September 20, 2017 10:59:56 Per Nordlöw via Digitalmars-d
> >>>
> >>> wrote:
> >>>> On Wednesday, 20 September 2017 at 09:13:52 UTC, Jonathan M Davis
> >>>>
> >>>> wrote:
> >>>>> https://issues.dlang.org/show_bug.cgi?id=12625
> >>>>>
> >>>>> - Jonathan M Davis
> >>>>
> >>>> Looks like we should we wait for
> >>>> https://github.com/dlang/dmd/pull/7110 to be merged before
> >>>> adding
> >>>> `s` to druntime.
> >>>
> >>> It also should have a much more descriptive name (e.g.
> >>> staticArray, though
> >>> maybe that's a bit long), and I think that std.array really
> >>> does make more
> >>> sense than object.d. object.d is for stuff that's essentially
> >>> built-in, not
> >>> for helper functions.
> >>
> >> Agreed. Also: the length of the name should not be a problem, this is not a frequently used facility. -- Andrei
> >
> > I do strongly disagree with this approach, rather we should type array literals as static arrays by default and rely on implicit conversion to slices.
>
> A long time ago I believe this was the case, but it was changed because it caused a lot of problems. What they were I don't know.

The simple fact that static arrays implicitly convert to dynamic arrays causes all kinds of problems. DIP 1000 should improve that situation (at least as far as memory safety goes), but in general, I'm convinced that having that implicit conversion was a serious mistake.

And as for specific problems with typing array literals as static arrays, the first thing that comes to mind is that it won't work with range-based functions, whereas as long as they're dynamic arrays, it will.

- Jonathan M Davis

On 9/20/17 1:36 AM, Andrei Alexandrescu wrote:
> On 9/19/17 8:47 PM, Steven Schveighoffer wrote:
>> This needs to happen.
>>
>> e.g.:
>>
>> char[$] arr = "hello"; // syntax up for debate, but I like this.
>>
>> I can't think of a correct way to do this that doesn't heap-allocate and is DRY.
>>
>> D is so powerful, it's a huge shame it can't figure this one out.
>>
>> issue: https://issues.dlang.org/show_bug.cgi?id=481
>>
>> Fix that was merged: https://github.com/dlang/dmd/pull/3615
>>
>> And then reverted: https://github.com/dlang/dmd/pull/4373
>>
>> Maybe there was an issue with the implementation? Can it be redone?
>>
> 
> The argument was it can be done trivially with a library solution.

As I said, I can't figure it out. Perhaps the triviality can be explained?

As Jonathan said, the VRP causes problems, because the compiler has more context than a library function. There is also the concern about needlessly generating templates and functions for every type and static array length combination, just for an initializer.

e.g., make this work without having to specify "3":

ubyte[3] = [1, 2, 3];

Thanks.

-Steve

On 9/20/17 3:12 AM, Dgame wrote:

> 
> http://p0nce.github.io/d-idioms/#@nogc-Array-Literals:-Breaking-the-Limits

This is plain stack corruption, you should fix that. The s template seems useful, but still I can't get my use case to work with it:

T[n] s(T, size_t n)(auto ref T[n] array) pure nothrow @nogc @safe
{
    return array;
}

void main()
{
    char[5] x1 = "hello"; // works.
    auto x2 = s("hello"); // oops, type is immutable(char[5]);
    auto x3 = s!char("hello"); // template s cannot deduce function from argument types !(char)(string)
}

-Steve

On Wednesday, 20 September 2017 at 14:15:30 UTC, Steven Schveighoffer wrote:
> On 9/20/17 3:12 AM, Dgame wrote:
>
>> 
>> http://p0nce.github.io/d-idioms/#@nogc-Array-Literals:-Breaking-the-Limits
>
> This is plain stack corruption, you should fix that. The s template seems useful, but still I can't get my use case to work with it:
>
> T[n] s(T, size_t n)(auto ref T[n] array) pure nothrow @nogc @safe
> {
>     return array;
> }
>
> void main()
> {
>     char[5] x1 = "hello"; // works.
>     auto x2 = s("hello"); // oops, type is immutable(char[5]);
>     auto x3 = s!char("hello"); // template s cannot deduce function from argument types !(char)(string)
> }
>
> -Steve

Works:
----
char[5] b = "hallo".s;
----

Otherwise you could simply use Unqual:
----
Unqual!T[n] s(T, size_t n)(T[n] arr)
{
	return arr;
}

auto a = "hallo".s;
writeln(typeof(a).stringof); // char[5]
----

On 09/20/2017 08:41 AM, Stefan Koch wrote:
> On Wednesday, 20 September 2017 at 12:08:45 UTC, Andrei Alexandrescu wrote:
>> On 09/20/2017 07:49 AM, Jonathan M Davis wrote:
>>> On Wednesday, September 20, 2017 10:59:56 Per Nordlöw via Digitalmars-d
>>> wrote:
>>>> On Wednesday, 20 September 2017 at 09:13:52 UTC, Jonathan M Davis
>>>>
>>>> wrote:
>>>>> https://issues.dlang.org/show_bug.cgi?id=12625
>>>>>
>>>>> - Jonathan M Davis
>>>>
>>>> Looks like we should we wait for
>>>> https://github.com/dlang/dmd/pull/7110 to be merged before adding
>>>> `s` to druntime.
>>>
>>> It also should have a much more descriptive name (e.g. staticArray, though
>>> maybe that's a bit long), and I think that std.array really does make more
>>> sense than object.d. object.d is for stuff that's essentially built-in, not
>>> for helper functions.
>>
>> Agreed. Also: the length of the name should not be a problem, this is not a frequently used facility. -- Andrei
> 
> I do strongly disagree with this approach, rather we should type array literals as static arrays by default and rely on implicit conversion to slices.

Can that be done without breakages? -- Andrei

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

On 9/20/17 11:48 AM, Dgame wrote:
> 
> Works:
> ----
> char[5] b = "hallo".s;
> ----

Sure, but completely misses the point!

> Otherwise you could simply use Unqual:
> ----
> Unqual!T[n] s(T, size_t n)(T[n] arr)
> {
>      return arr;
> }
> 
> auto a = "hallo".s;
> writeln(typeof(a).stringof); // char[5]
> ----

This might work better, although it's not necessarily what the user wants. It does solve my use case, so that is good! And it's much easier to declare something to be immutable or const than it is to force it to be mutable.

Still it can't handle the case of:

ubyte[3] x = [1, 2, 3];

-Steve

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]));
}
----

On 20.09.2017 18:34, Andrei Alexandrescu wrote:
>>
>> I do strongly disagree with this approach, rather we should type array literals as static arrays by default and rely on implicit conversion to slices.
> 
> Can that be done without breakages? -- Andrei

No.