www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - static array with inferred size

reply Steven Schveighoffer <schveiguy yahoo.com> writes:
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
Sep 19
next sibling parent reply Jonathan M Davis <newsgroup.d jmdavisprog.com> writes:
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
Sep 19
parent reply Meta <jared771 gmail.com> writes:
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&A'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/wagryggxehnbsbyhwkgf 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.
Sep 19
next sibling parent reply jmh530 <john.michael.hall gmail.com> writes:
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).
Sep 19
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
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
Sep 20
parent reply jmh530 <john.michael.hall gmail.com> writes:
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].
Sep 20
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
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
Sep 20
parent jmh530 <john.michael.hall gmail.com> writes:
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.
Sep 21
prev sibling parent Steven Schveighoffer <schveiguy yahoo.com> writes:
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
Sep 19
prev sibling next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
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
Sep 19
next sibling parent Jonathan M Davis <newsgroup.d jmdavisprog.com> writes:
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
Sep 19
prev sibling next sibling parent reply Dgame <r.schuett.1987 gmail.com> writes:
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
Sep 20
next sibling parent reply Jonathan M Davis <newsgroup.d jmdavisprog.com> writes:
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
Sep 20
parent reply =?UTF-8?B?Tm9yZGzDtnc=?= <per.nordlow gmail.com> writes:
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?
Sep 20
next sibling parent reply Dgame <r.schuett.1987 gmail.com> writes:
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.
Sep 20
parent =?UTF-8?B?Tm9yZGzDtnc=?= <per.nordlow gmail.com> writes:
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.
Sep 20
prev sibling parent reply Jonathan M Davis <newsgroup.d jmdavisprog.com> writes:
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
Sep 20
parent reply Per =?UTF-8?B?Tm9yZGzDtnc=?= <per.nordlow gmail.com> writes:
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.
Sep 20
parent reply Jonathan M Davis <newsgroup.d jmdavisprog.com> writes:
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
Sep 20
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
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
Sep 20
parent reply Stefan Koch <uplink.coder googlemail.com> writes:
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.
Sep 20
next sibling parent reply Meta <jared771 gmail.com> writes:
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.
Sep 20
parent Jonathan M Davis <newsgroup.d jmdavisprog.com> writes:
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
Sep 20
prev sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
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
Sep 20
parent reply Timon Gehr <timon.gehr gmx.ch> writes:
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.
Sep 20
parent reply Per =?UTF-8?B?Tm9yZGzDtnc=?= <per.nordlow gmail.com> writes:
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] ?
Sep 21
parent reply Timon Gehr <timon.gehr gmx.ch> writes:
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]`.
Sep 21
parent reply Dominikus Dittes Scherkl <Dominikus.Scherkl continental-corporation.com> writes:
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.
Sep 22
parent reply Steven Schveighoffer <schveiguy yahoo.com> writes:
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
Sep 22
parent Jonathan M Davis <newsgroup.d jmdavisprog.com> writes:
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
Sep 22
prev sibling parent reply Steven Schveighoffer <schveiguy yahoo.com> writes:
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
Sep 20
parent reply Dgame <r.schuett.1987 gmail.com> writes:
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] ----
Sep 20
parent reply Steven Schveighoffer <schveiguy yahoo.com> writes:
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
Sep 20
parent reply ag0aep6g <anonymous example.com> writes:
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])); } ----
Sep 20
parent Steven Schveighoffer <schveiguy yahoo.com> writes:
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
Sep 21
prev sibling parent Steven Schveighoffer <schveiguy yahoo.com> writes:
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
Sep 20
prev sibling parent Ilya <ilyayaroshenko gmail.com> writes:
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
Sep 19