Re: static array with inferred size
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
Re: static array with inferred size
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
Re: static array with inferred size
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.
Re: static array with inferred size
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.
Re: static array with inferred size
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]`.
Re: static array with inferred size
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
Re: static array with inferred size
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] ?
Re: static array with inferred size
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.
Re: static array with inferred size
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]));
}
Re: static array with inferred size
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
Re: static array with inferred size
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
Re: static array with inferred size
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
Re: static array with inferred size
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]
Re: static array with inferred size
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
Re: static array with inferred size
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
Re: static array with inferred size
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
Re: static array with inferred size
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.
Re: static array with inferred size
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.
Re: static array with inferred size
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].
Re: static array with inferred size
On 09/19/2017 11:05 PM, jmh530 wrote: On Wednesday, 20 September 2017 at 02:46:53 UTC, Meta wrote: [snip] I also favor making arr[..] equivalent to arr[0..$] How would this be useful? -- Andrei
Re: static array with inferred size
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
Re: static array with inferred size
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. - Jonathan M Davis
Re: static array with inferred size
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.
Re: static array with inferred size
On Wednesday, September 20, 2017 08:33:34 Nordlöw via Digitalmars-d wrote:
> On Wednesday, 20 September 2017 at 07:38:00 UTC, Jonathan M Davis
>
> wrote:
> > T[n] s(T, size_t n)(auto ref T[n] array) pure nothrow @nogc
> > @safe
> > {
> >
> > return array;
> >
> > }
>
> What about adding `s` to std.array in the meanwhile? I wonder
> what Walter says about the static array to slice assignment.
> Isn't it memory-safe?
If you use auto with the return value, you're fine, because you get a static
array, and the orignal static array is copied, but if you assign it to a
dynamic array, it's not at all memory safe. It's returning a slice of an
rvalue and is a clear violation of
https://issues.dlang.org/show_bug.cgi?id=12625
- Jonathan M Davis
Re: static array with inferred size
On Wednesday, 20 September 2017 at 08:39:49 UTC, Dgame wrote: Maybe even in object.d so that [1, 2, 3].s is possible without any import. Then it would look like a built-in feature. Good idea. Even better. I'll cook up a druntime-PR.
Re: static array with inferred size
On Wednesday, 20 September 2017 at 08:33:34 UTC, Nordlöw wrote:
On Wednesday, 20 September 2017 at 07:38:00 UTC, Jonathan M
Davis wrote:
T[n] s(T, size_t n)(auto ref T[n] array) pure nothrow @nogc
@safe
{
return array;
}
What about adding `s` to std.array in the meanwhile? I wonder
what Walter says about the static array to slice assignment.
Isn't it memory-safe?
Maybe even in object.d so that [1, 2, 3].s is possible without
any import. Then it would look like a built-in feature.
Re: static array with inferred size
On Wednesday, 20 September 2017 at 07:38:00 UTC, Jonathan M Davis
wrote:
T[n] s(T, size_t n)(auto ref T[n] array) pure nothrow @nogc
@safe
{
return array;
}
What about adding `s` to std.array in the meanwhile? I wonder
what Walter says about the static array to slice assignment.
Isn't it memory-safe?
Re: static array with inferred size
On Wednesday, September 20, 2017 07:12:15 Dgame via Digitalmars-d wrote:
> On Wednesday, 20 September 2017 at 05:36:43 UTC, 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?
> >>
> >> -Steve
> >
> > The argument was it can be done trivially with a library
> > solution. -- Andrei
>
> http://p0nce.github.io/d-idioms/#@nogc-Array-Literals:-Breaking-the-Limits
Yeah, it's a partial solution, but it won't work with VRP. e.g.
ubyte[4] = [1, 2, 3, 4];
is legal, but that won't work with that template.
https://issues.dlang.org/show_bug.cgi?id=16779
Also, that example
T[n] s(T, size_t n)(auto ref T[n] array) pure nothrow @nogc @safe
{
return array;
}
void main() @nogc
{
int[] myDynamicArray = [1, 2, 3].s; // Slice that static array which is
on stack
// Use myDynamicArray...
}
looks like it shouldn't even be legal, since the static array should be gone
as soon as the line where myDynamicArray is declared has passed. Using auto
should be fine, because then it would be a static array, and the data would
be copied to the stack, but assigning it to a dynamic array should be
illegal.
- Jonathan M Davis
Re: static array with inferred size
On Wednesday, 20 September 2017 at 05:36:43 UTC, 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? -Steve The argument was it can be done trivially with a library solution. -- Andrei http://p0nce.github.io/d-idioms/#@nogc-Array-Literals:-Breaking-the-Limits
Re: static array with inferred size
On Wednesday, 20 September 2017 at 00:47:25 UTC, Steven Schveighoffer wrote: This needs to happen. e.g.: char[$] arr = "hello"; // syntax up for debate, but I like this. Yes, hope to see this one day as a language feature, not a library solution. --Ilya
Re: static array with inferred size
On Wednesday, September 20, 2017 01:36:43 Andrei Alexandrescu via Digitalmars-d 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? > > > > -Steve > > The argument was it can be done trivially with a library solution. -- > Andrei I have yet to see a library solution that is able to accept the full range of arguments that you can give when you provide the length. The closest that I was able to come up with didn't work with VRP, and most of the other solutions I've seen only accept compile-time arguments, meaning that you can't having any variables in the elements used to initialize the static array. I opened https://issues.dlang.org/show_bug.cgi?id=16779 a while ago, since with that enhancement implemented, it _is_ possible to do the same thing that T[$] = would do, but without that, I don't know of any way to get the full functionality that we get right now when the size isn't inferred. Now, I think that something like T[$] = is a very improvement syntactically, so I'd be in favor of it anyway, but regardless, as far as I can tell, if we want this full functionality, we need to improve to the language/compiler - be it by adding syntax for infering the size to the language itself or by fixing it so that VRP works properly with IFTI and auto ref. - Jonathan M Davis
Re: static array with inferred size
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? -Steve The argument was it can be done trivially with a library solution. -- Andrei
Re: static array with inferred size
On 9/19/17 10:46 PM, Meta wrote: With all due respect to Andrei, I think he overreacted a bit and it was a mistake to revert static array length deduction (although the array/aa type deduction on steroids was probably overly complicated so that was a good call). Maybe now that @nogc and betterC are squarely in focus we can revisit array length deduction. The length deduction is so obviously needed, especially when you want to avoid heap allocations. char["hello".length] = "hello"; It's just so terrible. I can't figure out a good way around it. Deducing types is probably reasonable as a request, but I don't see how one requires the other. There is no need to repeat the entire literal to form the type, and you aren't specifying the type anyway. At most you have to enter the type one more time (in the case of explictly typing an element). But having to manually count all the elements in an array literal? That is torture! D should be better than that. -Steve
Re: static array with inferred size
On Wednesday, 20 September 2017 at 02:46:53 UTC, Meta wrote: [snip] I also favor making arr[..] equivalent to arr[0..$] and allowing overloading of \ (for inverse, similar syntax as Matlab).
Re: static array with inferred size
On Wednesday, 20 September 2017 at 01:29:39 UTC, Jonathan M Davis wrote: On Tuesday, September 19, 2017 20:47:25 Steven Schveighoffer via Digitalmars-d 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? All in all, I think that it would be cleanest if this were just implemented in the language. I recall there being discussions about adding it with the syntax you showed, and on reflection, I _think_ that I recall Walter objecting to it for some reason, which is why it was reverted, but I don't remember the details at all at this point, so I could easily be remembering incorrectly. That was the main reason it was reverted. A contributing factor is that Beadophile had been trying to push this feature for a long time, and once it got in (against W's reservations, although they eventually gave the okay) he started pushing harder for the []s syntax for static array literals, arguing that now that we had static array length deduction syntax we needed static array literal syntax as well. This was the straw that broke the camel's back for Andrei and he decided to revert the length deduction PR citing concerns over feature bloat. There was also other functionality tied up with the deduction syntax - see this post: https://forum.dlang.org/post/wagryggxehnbsbyhw...@forum.dlang.org With all due respect to Andrei, I think he overreacted a bit and it was a mistake to revert static array length deduction (although the array/aa type deduction on steroids was probably overly complicated so that was a good call). Maybe now that @nogc and betterC are squarely in focus we can revisit array length deduction.
Re: static array with inferred size
On Tuesday, September 19, 2017 20:47:25 Steven Schveighoffer via Digitalmars-d 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? There have been previous attempts to implement this as a library solution. IIRC, I was able to come up with a solution that would have been equivalent, but I hit this issue with the compiler that prevented it: https://issues.dlang.org/show_bug.cgi?id=16779 My solution would work so long as you gave up on VRP, and there are other solutions which work in some cases but not all (e.g. requiring that all of the elements of the array be known at compile time and thus disallowing stuff like [42, a, 7, 9, b] where a and b are variables). I'm not aware of any library solution which would infer the size that would have the full functionality that you can get now when initializing a static array without trying to infer the size. All in all, I think that it would be cleanest if this were just implemented in the language. I recall there being discussions about adding it with the syntax you showed, and on reflection, I _think_ that I recall Walter objecting to it for some reason, which is why it was reverted, but I don't remember the details at all at this point, so I could easily be remembering incorrectly. Regardless, if we want the full functionality, we need improvements to the compiler/language - be it implementing my enhancement request with regards to VRP so that a library solution could work and/or by actually adding the static array size inference feature to the language itself. - Jonathan M Davis
