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 2017
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 2017
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 2017
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 2017
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 2017
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 2017
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 2017
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 2017
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 2017
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 2017
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 2017
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
Sep 20 2017
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





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 2017
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 2017
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 2017
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 2017
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 2017
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 2017
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 2017
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 2017
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 2017
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 2017
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 2017
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 2017
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 2017
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 2017
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 2017
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 2017
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 2017
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 2017
prev sibling parent reply Steven Schveighoffer <schveiguy yahoo.com> writes:
On 9/20/17 3:12 AM, Dgame wrote:


 



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 2017
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:


 



 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 2017
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 2017
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 2017
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 2017
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 2017
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 2017