www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - auto arr = [1, 2, 3] should be a static array, not a GC allocated

reply ryuukk_ <ryuukk.dev gmail.com> writes:
It is misleading, nobody expect this to be GC allocated

It should be equal to:

```D
int[3] arr = [1, 2, 3]
```

Also why it is GC allocated without requiring ``new``?
Jul 14 2022
next sibling parent reply jfondren <julian.fondren gmail.com> writes:
On Thursday, 14 July 2022 at 13:14:59 UTC, ryuukk_ wrote:

 It is misleading, nobody expect this to be GC allocated


People expect that who try to append to it later on in the 
function. The book "Learning D" really emphasizes stuff like 
this, useful but potentially surprising parts of the native types 
of the language.

All languages have stuff like this. D has a performance hazard in 
treating dynamic arrays like stacks; Go avoids that while having 
the fun design where appending to a slice might modify a 
different slice.


 It should be equal to:

 ```D
 int[3] arr = [1, 2, 3]
 ```

 Also why it is GC allocated without requiring ``new``?


D doesn't have a principle like "GC allocations should all be 
signposted with `new`". These visual-signposting principles are 
neat and all, but as long as the language has pervasive 
function-calling, every single one can violate the principle. 
What D *does* have is ` nogc`

https://dlang.org/spec/garbage.html#op_involving_gc
Jul 14 2022
next sibling parent reply ryuukk_ <ryuukk.dev gmail.com> writes:
On Thursday, 14 July 2022 at 13:30:58 UTC, jfondren wrote:

 On Thursday, 14 July 2022 at 13:14:59 UTC, ryuukk_ wrote:

 It is misleading, nobody expect this to be GC allocated


 People expect that who try to append to it later on in the 
 function. The book "Learning D" really emphasizes stuff like 
 this, useful but potentially surprising parts of the native 
 types of the language.


Then the compiler should tell them that it is a static array and 
they should be explicit if they want to append

Corner cases from clueless people shouldn't make the default 
useless and misleading



 All languages have stuff like this. D has a performance hazard 
 in treating dynamic arrays like stacks; Go avoids that while 
 having the fun design where appending to a slice might modify a 
 different slice.



I disagree hard, not "all languages have stuff like this" D has 
stuff like this


again, who's the target audience of D?


 It should be equal to:

 ```D
 int[3] arr = [1, 2, 3]
 ```

 Also why it is GC allocated without requiring ``new``?


 D doesn't have a principle like "GC allocations should all be 
 signposted with `new`". These visual-signposting principles are 
 neat and all, but as long as the language has pervasive 
 function-calling, every single one can violate the principle. 
 What D *does* have is ` nogc`

 https://dlang.org/spec/garbage.html#op_involving_gc


It is a mistake then

Little rant:

As time goes by, i'm thinking more and more to finally learn 
language programming and fork D to get rid of all these stuff 
that makes me want to look for an alternative language

Every once in a while i get reminded why i had that thought, 
thanks to issues i encounter like this one, very frustrating when 
you take into account that nobody wants new features and instead 
want to rely on template soup indefinitely

static arrays? just use

```D
  import std;
  auto arr staticArray!int(1,2, 3);
```

"no need to change the language"
Jul 14 2022
next sibling parent reply jfondren <julian.fondren gmail.com> writes:
On Thursday, 14 July 2022 at 14:37:34 UTC, ryuukk_ wrote:

 Then the compiler should tell them that it is a static array 
 and they should be explicit if they want to append

 Corner cases from clueless people shouldn't make the default 
 useless and misleading


Instead of the compiler telling those clueless people that their 
expectations were wrong, it's telling you that your expectations 
are wrong. And you want me to have no sympathy for people like 
that? I mean, if you really want that, OK:

It has to be one way or the other, and it's the way it is, and 
it's useful and it makes sense. Dynamic arrays are a 
high-convenience feature, so convenient you don't even have to 
care about their storage, and they're very naturally preferred by 
the convenience feature of not even having to say what type a 
value has.

Static arrays are still very nice in D, especially their array 
ops https://dlang.org/spec/arrays.html#array-operations , but 
they require extra care in more ways than this.
Jul 14 2022
parent Salih Dincer <salihdb hotmail.com> writes:
On Thursday, 14 July 2022 at 15:13:07 UTC, jfondren wrote:

 Static arrays are still very nice in D, especially their array 
 ops https://dlang.org/spec/arrays.html#array-operations , but 
 they require extra care in more ways than this.


I think the topic is conclude... Criticisms were made and 
requests received.  In the specs, the [12.12 Static Array 
title](https://dlang.org/spec/arrays.html#static-arrays) says:


 5.3.Because static arrays are passed to functions by value, a 
 larger array can consume a lot of stack space. Use dynamic 
 arrays instead.


Is it necessary to open a new topic but I need more explanation?

SDB 79
Jul 19 2022
prev sibling parent reply Paulo Pinto <pjmlp progtools.org> writes:
On Thursday, 14 July 2022 at 14:37:34 UTC, ryuukk_ wrote:

 On Thursday, 14 July 2022 at 13:30:58 UTC, jfondren wrote:

 On Thursday, 14 July 2022 at 13:14:59 UTC, ryuukk_ wrote:

 It is misleading, nobody expect this to be GC allocated


 People expect that who try to append to it later on in the 
 function. The book "Learning D" really emphasizes stuff like 
 this, useful but potentially surprising parts of the native 
 types of the language.


 Then the compiler should tell them that it is a static array 
 and they should be explicit if they want to append

 Corner cases from clueless people shouldn't make the default 
 useless and misleading



 All languages have stuff like this. D has a performance hazard 
 in treating dynamic arrays like stacks; Go avoids that while 
 having the fun design where appending to a slice might modify 
 a different slice.



 I disagree hard, not "all languages have stuff like this" D has 
 stuff like this


 again, who's the target audience of D?



contexts with Span<> types, your expectations can be fulfilled 
with

```csharp
    Span<int> arr = stackalloc int[] {1, 2, 3};
```

Godbolt link, https://godbolt.org/z/6b6MMPe7v

While Java is getting them when Valhala finally gets integrated.
Jul 14 2022
parent Salih Dincer <salihdb hotmail.com> writes:
On Friday, 15 July 2022 at 05:50:33 UTC, Paulo Pinto wrote:

 
 ```csharp
    Span<int> arr = stackalloc int[] {1, 2, 3};
 ```



D:


 The programmer must remember to update the integer literal in 
 the static array declaration from 2 to 3, else face a compiler 
 error.


SDB 79
Jul 14 2022
prev sibling parent reply Ogi <ogion.art gmail.com> writes:
On Thursday, 14 July 2022 at 13:30:58 UTC, jfondren wrote:

 On Thursday, 14 July 2022 at 13:14:59 UTC, ryuukk_ wrote:

 It is misleading, nobody expect this to be GC allocated


 People expect that who try to append to it later on in the 
 function.


And this also should be killed with fire. We need a clean 
distinction between static arrays, GC-controlled dynamic arrays, 
and slices.
Jul 16 2022
parent Araq <rumpf_a web.de> writes:
On Saturday, 16 July 2022 at 15:12:19 UTC, Ogi wrote:

 On Thursday, 14 July 2022 at 13:30:58 UTC, jfondren wrote:

 On Thursday, 14 July 2022 at 13:14:59 UTC, ryuukk_ wrote:

 It is misleading, nobody expect this to be GC allocated


 People expect that who try to append to it later on in the 
 function.


 And this also should be killed with fire. We need a clean 
 distinction between static arrays, GC-controlled dynamic 
 arrays, and slices.


Correct but that's just one out of many examples where C++ is 
simply better designed. C++'s references work better than D's 
`inout`, C++'s const system works better as it allows for 
reference counted containers ("logical constness"), D's postblits 
had to be replaced with copy constructors (like C++ does it), 
`shared` doesn't mean anything (C++ lacks it), D's class 
construct introduces a value vs pointer semantics schism that C++ 
consciously avoided, D's class construct comes with a monitor 
(C++ does not have this overhead), C++ does not misuse the `enum` 
keyword, C++ lacks an effect system like  nogc  safe  etc that 
simply gets in the way, C++ doesn't need "interface", it allows 
for multiple inheritance instead so that's an entire entity that 
it lacks as it doesn't need it.

Now you can disagree with this list all you want and point out 
details which I got wrong but the point here is: Don't be 
surprised that D never really replaced C++, it's not the lack of 
marketing and it's not the lack of manpower either, the language 
is not designed all that well and it didn't learn much from C++.
Jul 16 2022
prev sibling next sibling parent reply bachmeier <no spam.net> writes:
On Thursday, 14 July 2022 at 13:14:59 UTC, ryuukk_ wrote:

 It is misleading, nobody expect this to be GC allocated

 It should be equal to:

 ```D
 int[3] arr = [1, 2, 3]
 ```

 Also why it is GC allocated without requiring ``new``?



 nobody expect this to be GC allocated


Maybe I'm not fully awake, but why would anyone expect this to 
*not* be GC allocated?
Jul 14 2022
parent reply Dave P. <dave287091 gmail.com> writes:
On Thursday, 14 July 2022 at 14:51:01 UTC, bachmeier wrote:

 On Thursday, 14 July 2022 at 13:14:59 UTC, ryuukk_ wrote:

 It is misleading, nobody expect this to be GC allocated

 It should be equal to:

 ```D
 int[3] arr = [1, 2, 3]
 ```

 Also why it is GC allocated without requiring ``new``?



 nobody expect this to be GC allocated


 Maybe I'm not fully awake, but why would anyone expect this to 
 *not* be GC allocated?


Similar syntax in C is for a static array of inferred length:

```C
int arr[] = {1,2,3};
```

D has no way to express a similar concept without being horribly 
verbose with `.staticArray`.
Jul 14 2022
next sibling parent reply jfondren <julian.fondren gmail.com> writes:
On Thursday, 14 July 2022 at 15:26:44 UTC, Dave P. wrote:

 Similar syntax in C is for a static array of inferred length:

 ```C
 int arr[] = {1,2,3};
 ```


ehh, isn't that a C99 feature? I'm still waiting for compilers to 
support it.

D has support for the older way of needing a redundant length, 
and D errors out if the length is wrong in most cases. Still, I 
also wanted inferred length with a feature like `int[_] arr`.

There are little conveniences like this where D's losing out 
against the state out of the art in 'older' languages: C got 
inferred length, C has named-member struct literals that D 
doesn't like, C++ has structured bindings.


 D has no way to express a similar concept without being 
 horribly verbose with `.staticArray`.


Also:

```d
enum nums = [1, 2, 3];
int[nums.length] arr = nums;
```

I'd never do exactly that, but keeping n array in compile-time 
and only statically picking from it is an option, with ` nogc` 
protecting you from accidentally building it.
Jul 14 2022
next sibling parent Dave P. <dave287091 gmail.com> writes:
On Thursday, 14 July 2022 at 16:50:40 UTC, jfondren wrote:

 On Thursday, 14 July 2022 at 15:26:44 UTC, Dave P. wrote:

 Similar syntax in C is for a static array of inferred length:

 ```C
 int arr[] = {1,2,3};
 ```


 ehh, isn't that a C99 feature? I'm still waiting for compilers 
 to support it.


It’s a C89 feature, it’s in my copy of The C Programming language.
Jul 14 2022
prev sibling parent reply =?UTF-8?Q?Ali_=c3=87ehreli?= <acehreli yahoo.com> writes:
On 7/14/22 09:50, jfondren wrote:


 inferred length with a feature like `int[_] arr`.


Is there a reason why that can't be added to D? I don't see any downside.[1]

Ali

[1] Other than bike-shedding:

- int[$]      // Not perfect because the array does not have a length
               // (yet) but $ means exactly that in other contexts.

- int[auto]   // Better but 'auto' means "type" to me.

- int[static] // Aaaah... good old 'static' to the rescue. :D

- int[{}]     // Meaning "take the length from the initializer".
               // (Yes, I am joking.)

- int[=]      // Because this is initialization after all.

- int[+]      // Meaning: "Please count for me."

- int[∑1]     // Ditto but because not all keyboards have that
               // character, the alternative tetragraph is proposed
               // below.

- int[???<1]  // Readable enough? :o)
Jul 14 2022
next sibling parent jfondren <julian.fondren gmail.com> writes:
On Thursday, 14 July 2022 at 17:57:13 UTC, Ali Çehreli wrote:

 On 7/14/22 09:50, jfondren wrote:


 inferred length with a feature like `int[_] arr`.


 Is there a reason why that can't be added to D? I don't see any 
 downside.[1]

 Ali


Unfortunately _ is a valid identifier:

```d
enum _ = 3;
int[_] nums = [1, 2, 3];
assert(_ == 3);
```


 [1] Other than bike-shedding:

 - int[$]      // Not perfect because the array does not have a 
 length
               // (yet) but $ means exactly that in other 
 contexts.


And `enum $ = 3` is an error.
Jul 14 2022
prev sibling next sibling parent reply "H. S. Teoh" <hsteoh qfbox.info> writes:
On Thu, Jul 14, 2022 at 10:57:13AM -0700, Ali Çehreli via Digitalmars-d wrote:

 On 7/14/22 09:50, jfondren wrote:
 

 inferred length with a feature like `int[_] arr`.


 
 Is there a reason why that can't be added to D? I don't see any
 downside.[1]
 
 Ali
 
 [1] Other than bike-shedding:
 
 - int[$]      // Not perfect because the array does not have a length
               // (yet) but $ means exactly that in other contexts.


IMO, this is the best bikeshed color. :-P



 - int[auto]   // Better but 'auto' means "type" to me.
 
 - int[static] // Aaaah... good old 'static' to the rescue. :D


Argh, please no!! `static` is already overloaded too much in D, please
don't make it worse.



 - int[{}]     // Meaning "take the length from the initializer".
               // (Yes, I am joking.)


This one made me cringe. :-/



 - int[=]      // Because this is initialization after all.
 
 - int[+]      // Meaning: "Please count for me."


These are bad for the parser, because the current language expects a
numerical expression between the [].



 - int[∑1]     // Ditto but because not all keyboards have that
               // character, the alternative tetragraph is proposed
               // below.
 
 - int[???<1]  // Readable enough? :o)


OK, either you're pulling my leg, or I must have missed some memo about
... I dunno what. :-D

//

But anyway, this is by far not the first time this issue has been
brought up, and it's high time we made some progress on it.  Where's the
DIP when you need it?  Actually, I'm almost certain somebody already
wrote the DIP, and IIRC even implemented it in a dmd branch.  We should
resurrect the DIP/implementation and push it through.  It has been too
many years.


T

-- 
"The number you have dialed is imaginary. Please rotate your phone 90 degrees
and try again."
Jul 14 2022
next sibling parent reply =?UTF-8?Q?Ali_=c3=87ehreli?= <acehreli yahoo.com> writes:
On 7/14/22 11:29, H. S. Teoh wrote:


 - int[static] // Aaaah... good old 'static' to the rescue. :D


 Argh, please no!! `static` is already overloaded too much in D, please
 don't make it worse.


I don't think 'static' can get any worse. Would the following make this 
use case stand out more?

   int[static static]  // Oooh! Me likes...


 OK, either you're pulling my leg


Was that too subtle? :) Yes, I was having fun.

Ali
Jul 14 2022
parent reply "H. S. Teoh" <hsteoh qfbox.info> writes:
On Thu, Jul 14, 2022 at 11:36:20AM -0700, Ali Çehreli via Digitalmars-d wrote:

 On 7/14/22 11:29, H. S. Teoh wrote:
 

 - int[static] // Aaaah... good old 'static' to the rescue. :D


 Argh, please no!! `static` is already overloaded too much in D,
 please don't make it worse.


 
 I don't think 'static' can get any worse. Would the following make
 this use case stand out more?
 
   int[static static]  // Oooh! Me likes...


Maybe int[static array] would make it much more obvious to newbies. ;-)



 OK, either you're pulling my leg


 
 Was that too subtle? :) Yes, I was having fun.


[...]

Let's bring the fun back to programming(tm)! ;-)


T

-- 
People tell me that I'm skeptical, but I don't believe them.
Jul 14 2022
parent reply =?UTF-8?Q?Ali_=c3=87ehreli?= <acehreli yahoo.com> writes:
On 7/14/22 11:55, H. S. Teoh wrote:


 Maybe int[static array] would make it much more obvious to newbies. ;-)


Looks good but 'array' is a legal identifier. :( Luckily nothing some 
creative acrostic can't fix:

   int[static alias,ref,return,assert,'y'] arr;

(Programmers would be free to use any keyword they like.)

That 'y' literal is an obvious eye sore. So we can expand the syntax to 
specify which character of each keyword is used for the acrostic. I 
utilize 'static' for that purpose as well:

   // 0-based indexing for consistency
   int[static static(1)
              ,cast
              ,break
              ,private
              ,false
              ,synchronized] arr;
           //   ^
           //   |
           // Character 1 of each keyword reads "array"

Ok, too much silliness for one day. I stop here.

Ali
Jul 14 2022
parent reply "H. S. Teoh" <hsteoh qfbox.info> writes:
On Thu, Jul 14, 2022 at 12:18:34PM -0700, Ali Çehreli via Digitalmars-d wrote:

 On 7/14/22 11:55, H. S. Teoh wrote:
 

 Maybe int[static array] would make it much more obvious to newbies. ;-)


 
 Looks good but 'array' is a legal identifier. :( Luckily nothing some
 creative acrostic can't fix:
 
   int[static alias,ref,return,assert,'y'] arr;


[...]

 Ok, too much silliness for one day. I stop here.


[...]

But but but... this is proposed syntax for automatically detecting the
length of a static array.  At the very least, it should spell out this
fact:

	int[auto static pragma(array, length)] arr;

The pragma, of course, is to provide a context where legal identifiers
have special meaning. :-D

On a serious note, though, int[$] is ideal.


T

-- 
Music critic: "That's an imitation fugue!"
Jul 14 2022
parent wjoe <invalid example.com> writes:
On Thursday, 14 July 2022 at 19:39:17 UTC, H. S. Teoh wrote:

 On Thu, Jul 14, 2022 at 12:18:34PM -0700, Ali Çehreli via 
 Digitalmars-d wrote:

 On 7/14/22 11:55, H. S. Teoh wrote:
 

 Maybe int[static array] would make it much more obvious to 
 newbies. ;-)


 
 Looks good but 'array' is a legal identifier. :( Luckily 
 nothing some creative acrostic can't fix:
 
   int[static alias,ref,return,assert,'y'] arr;


 [...]

 Ok, too much silliness for one day. I stop here.


 [...]

 But but but... this is proposed syntax for automatically 
 detecting the length of a static array.  At the very least, it 
 should spell out this fact:

 	int[auto static pragma(array, length)] arr;

 The pragma, of course, is to provide a context where legal 
 identifiers have special meaning. :-D

 On a serious note, though, int[$] is ideal.


 T


auto[staticsupercalifragilisticexpialidocious:)] = [1, 2, 3];
Jul 14 2022
prev sibling parent Steven Schveighoffer <schveiguy gmail.com> writes:
On Thursday, 14 July 2022 at 18:29:43 UTC, H. S. Teoh wrote:

 On Thu, Jul 14, 2022 at 10:57:13AM -0700, Ali Çehreli via 
 Digitalmars-d wrote:

 [1] Other than bike-shedding:
 
 - int[$]      // Not perfect because the array does not have a 
 length
               // (yet) but $ means exactly that in other 
 contexts.


 IMO, this is the best bikeshed color. :-P


Agreed.


 But anyway, this is by far not the first time this issue has 
 been brought up, and it's high time we made some progress on 
 it.  Where's the DIP when you need it?  Actually, I'm almost 
 certain somebody already wrote the DIP, and IIRC even 
 implemented it in a dmd branch.  We should resurrect the 
 DIP/implementation and push it through.  It has been too many 
 years.


https://github.com/dlang/DIPs/blob/master/DIPs/other/DIP1039.md

-Steve
Jul 16 2022
prev sibling next sibling parent Salih Dincer <salihdb hotmail.com> writes:
On Thursday, 14 July 2022 at 17:57:13 UTC, Ali Çehreli wrote:

 On 7/14/22 09:50, jfondren wrote:


 inferred length with a feature like `int[_] arr`.


 Is there a reason why that can't be added to D? I don't see any 
 downside.


Also think about it this way: If everything was inferenced, there 
would be no need for a programmer.

Ali's analogies are actually about us programmers being friends 
with numbers. We need numbers and right on data, to see the 
truth...
Jul 14 2022
prev sibling parent reply Basile B. <b2.temp gmx.com> writes:
On Thursday, 14 July 2022 at 17:57:13 UTC, Ali Çehreli wrote:

 - int[$]      // Not perfect because the array does not have a 
 length


I wanted to implement that in my language and found a subtle 
problem that makes the implementation of the feature a not so 
nice looking special case : the semantics of `int[$]` require the 
initializer unlike `auto`, which can be directly replaced by the 
initializer type. That breaks the binary and (somewhat ideal) 
approach of either `auto` and replace or full type and implicit 
conv of the initializer.
Jul 14 2022
parent jfondren <julian.fondren gmail.com> writes:
On Thursday, 14 July 2022 at 19:57:24 UTC, Basile B. wrote:

 On Thursday, 14 July 2022 at 17:57:13 UTC, Ali Çehreli wrote:

 - int[$]      // Not perfect because the array does not have a 
 length


 I wanted to implement that in my language and found a subtle 
 problem that makes the implementation of the feature a not so 
 nice looking special case : the semantics of `int[$]` require 
 the initializer unlike `auto`, which can be directly replaced 
 by the initializer type. That breaks the binary and (somewhat 
 ideal) approach of either `auto` and replace or full type and 
 implicit conv of the initializer.


dmd already comes very close, though:

```d
unittest {
     int[2] arr = [1, 2, 3];
}
```

This fails to compile with "Error: mismatched array lengths, 2 
and 3". So, treat `$` in `int[$]` like it's a random number, 
which already works, but then when you get to checking the 
lengths, accept 3 as the length of the array.
Jul 14 2022
prev sibling next sibling parent reply bachmeier <no spam.net> writes:
On Thursday, 14 July 2022 at 15:26:44 UTC, Dave P. wrote:

 On Thursday, 14 July 2022 at 14:51:01 UTC, bachmeier wrote:

 On Thursday, 14 July 2022 at 13:14:59 UTC, ryuukk_ wrote:

 It is misleading, nobody expect this to be GC allocated

 It should be equal to:

 ```D
 int[3] arr = [1, 2, 3]
 ```

 Also why it is GC allocated without requiring ``new``?



 nobody expect this to be GC allocated


 Maybe I'm not fully awake, but why would anyone expect this to 
 *not* be GC allocated?


 Similar syntax in C is for a static array of inferred length:

 ```C
 int arr[] = {1,2,3};
 ```


That would be a potential justification. OP claims nobody would 
expect a dynamic array, though, and matching C's behavior hardly 
makes the design choice obvious.


 D has no way to express a similar concept without being 
 horribly verbose with `.staticArray`.


OP wanted it to act the same as `int[3] arr = [1, 2, 3]`, so 
clearly there is.
Jul 14 2022
parent reply Dave P. <dave287091 gmail.com> writes:
On Thursday, 14 July 2022 at 17:33:22 UTC, bachmeier wrote:

 On Thursday, 14 July 2022 at 15:26:44 UTC, Dave P. wrote:

 On Thursday, 14 July 2022 at 14:51:01 UTC, bachmeier wrote:

 On Thursday, 14 July 2022 at 13:14:59 UTC, ryuukk_ wrote:

 It is misleading, nobody expect this to be GC allocated
 [...]






 That would be a potential justification. OP claims nobody would 
 expect a dynamic array, though, and matching C's behavior 
 hardly makes the design choice obvious.


Yes, I forgot to write the other half of my comment. I am also 
annoyed by this behavior, but I would be able to work around it 
if there was a convenient way to specify a static array of 
inferred length. Ansi C has this, D does not.
Jul 14 2022
parent reply Mike Parker <aldacron gmail.com> writes:
On Thursday, 14 July 2022 at 17:46:18 UTC, Dave P. wrote:


 Yes, I forgot to write the other half of my comment. I am also 
 annoyed by this behavior, but I would be able to work around it 
 if there was a convenient way to specify a static array of 
 inferred length. Ansi C has this, D does not.


There was a DIP for it, but the author withdrew it. Anyone is 
free to pick up where he left off:

https://github.com/dlang/DIPs/blob/master/DIPs/other/DIP1039.md
Jul 14 2022
parent reply Salih Dincer <salihdb hotmail.com> writes:
On Friday, 15 July 2022 at 02:14:53 UTC, Mike Parker wrote:

 On Thursday, 14 July 2022 at 17:46:18 UTC, Dave P. wrote:


 Yes, I forgot to write the other half of my comment. I am also 
 annoyed by this behavior, but I would be able to work around 
 it if there was a convenient way to specify a static array of 
 inferred length. Ansi C has this, D does not.


 There was a DIP for it, but the author withdrew it. Anyone is 
 free to pick up where he left off:

 https://github.com/dlang/DIPs/blob/master/DIPs/other/DIP1039.md


I can hear Walter yelling for the DIPs 7 years ago: Again? No!


 This change breaks existing code, requires an awkward 
 workaround for existing uses, and has only a marginal benefit. 
 At this point, I'm opposed to it.


It was written by Walter 10 years ago 😀

SDB 79
Jul 14 2022
parent Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Friday, 15 July 2022 at 06:17:26 UTC, Salih Dincer wrote:

 On Friday, 15 July 2022 at 02:14:53 UTC, Mike Parker wrote:

 On Thursday, 14 July 2022 at 17:46:18 UTC, Dave P. wrote:


 Yes, I forgot to write the other half of my comment. I am 
 also annoyed by this behavior, but I would be able to work 
 around it if there was a convenient way to specify a static 
 array of inferred length. Ansi C has this, D does not.


 There was a DIP for it, but the author withdrew it. Anyone is 
 free to pick up where he left off:

 https://github.com/dlang/DIPs/blob/master/DIPs/other/DIP1039.md


 I can hear Walter yelling for the DIPs 7 years ago: Again? No!


But now you can just point out that C++ does it...
Jul 14 2022
prev sibling parent reply Dukc <ajieskola gmail.com> writes:
On Thursday, 14 July 2022 at 15:26:44 UTC, Dave P. wrote:

 D has no way to express a similar concept without being 
 horribly verbose with `.staticArray`.


```D
import std : sa = staticArray;
//or if you don't want to rename in the import:
alias sa = std.staticArray;
```

I admit it's annoying to do because it's so non-standard to 
rename stuff like this. I'd do this if I was using `staticArray` 
a lot, but not in the general case.
Jul 16 2022
parent reply Salih Dincer <salihdb hotmail.com> writes:
On Saturday, 16 July 2022 at 16:44:16 UTC, Dukc wrote:

 On Thursday, 14 July 2022 at 15:26:44 UTC, Dave P. wrote:

 D has no way to express a similar concept without being 
 horribly verbose with `.staticArray`.


 ```D
 import std : sa = staticArray;
 //or if you don't want to rename in the import:
 alias sa = std.staticArray;
 ```


```d
   import std : sa = staticArray;
   auto sar = [1, 2, 3].sa; // really, looks short&easy
```

Why can't we use this with the byte type?

```d
   auto arr = sa!(long, [1, 2, 3]);
   assert(is(typeof(arr) : long[3])); // ok

   //auto noCompile = sa!(byte, [1, 2, 3]);
```

SDB 79
Jul 16 2022
parent reply Paul Backus <snarwin gmail.com> writes:
On Saturday, 16 July 2022 at 18:00:40 UTC, Salih Dincer wrote:

 Why can't we use this with the byte type?

 ```d
   auto arr = sa!(long, [1, 2, 3]);
   assert(is(typeof(arr) : long[3])); // ok

   //auto noCompile = sa!(byte, [1, 2, 3]);
 ```


Because the literal `[1, 2, 3]` is considered an `int` array 
literal, not a `byte` array literal.

It works if you use an explicit cast:

```d
auto arr = staticArray(cast(byte[]) [1, 2, 3]);
static assert(is(typeof(arr) == byte[3])); // ok
```
Jul 16 2022
parent reply Salih Dincer <salihdb hotmail.com> writes:
On Saturday, 16 July 2022 at 18:59:52 UTC, Paul Backus wrote:

 Because the literal `[1, 2, 3]` is considered an `int` array 
 literal, not a `byte` array literal.

 It works if you use an explicit cast:

 ```d
 auto arr = staticArray(cast(byte[]) [1, 2, 3]);
 static assert(is(typeof(arr) == byte[3])); // ok
 ```


Thank you, but this complicates things! Because it makes using 
staticArray unnecessary:

```d
   auto def = sa(cast(char[3]) [100, 101, 102]);
   assert(is(typeof(def) : char[3]));

   import std.stdio;

   auto cdef = cast(char[4]) [99, 100, 101, 102];
   cdef.writeln; // "cdef"
```

I think DIP1039 should be opened for review in the next version 
urgently.

SDB 79
Jul 17 2022
parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Sunday, 17 July 2022 at 07:04:01 UTC, Salih Dincer wrote:

 I think DIP1039 should be opened for review in the next version 
 urgently.


Why urgent? Nothing prevents you from creating your own 
‘mkarray!char(1,2,3,4)’?

The focus should be on things that matters, more special syntax 
is not a net positive.

New features ought to be more generic, like deduction guides in 
C++.
Jul 17 2022
parent reply Salih Dincer <salihdb hotmail.com> writes:
On Sunday, 17 July 2022 at 07:25:18 UTC, Ola Fosheim Grøstad 
wrote:

 On Sunday, 17 July 2022 at 07:04:01 UTC, Salih Dincer wrote:

 I think DIP1039 should be opened for review in the next 
 version urgently.


 Why urgent? Nothing prevents you from creating your own 
 ‘mkarray!char(1,2,3,4)’?


Because it is a proposal that has been forgotten for 7 years. The 
DIP may have been withdrawn, but it was never given a chance to 
be tried.

SDB 79
Jul 17 2022
parent reply Mike Parker <aldacron gmail.com> writes:
On Sunday, 17 July 2022 at 08:58:58 UTC, Salih Dincer wrote:


 Because it is a proposal that has been forgotten for 7 years. 
 The DIP may have been withdrawn, but it was never given a 
 chance to be tried.


It hasn't been 7 years. DIP 1039 went through the first round of 
Community review in January of last year. The author withdrew it 
because the he got the impression that the feedback was largely 
negative, and he felt that he couldn't formulate a good case for 
why the proposed feature was sufficiently of more benefit than 
`staticArray` to justify the new syntax.

You can see the review summary and the links to the Discussion 
and Feedback threads here:

https://github.com/dlang/DIPs/blob/master/DIPs/other/DIP1039.md#reviews

Again, anyone who wants to take this up is totally free to do so.

On a personal note, I like the idea. Having to match static array 
length with initializer length has annoyed me more than once in 
my years of D. And having to import another symbol to get around 
it hardly alleviates the annoyance. `int[$]` is a sensible syntax 
for it. So I hope someone does pick this up one day and manages 
to convince the right people that it's worth the implementation.
Jul 17 2022
next sibling parent Salih Dincer <salihdb hotmail.com> writes:
On Sunday, 17 July 2022 at 09:23:23 UTC, Mike Parker wrote:

 It hasn't been 7 years. DIP 1039 went through the first round 
 of Community review in January of last year.


Opps, sorry for my english. When I wrote "offer" I meant past 
requests. For example:

https://issues.dlang.org/show_bug.cgi?id=8008

Even this is from 10 years ago. I had seen something Kenji Hara 
shared before this but couldn't find it. In summary, there is a 
DIP, but the opportunity to use it is not given. Maybe as people 
use it, we will see how correct this decision is.

Thanks...

SDB 79
Jul 17 2022
prev sibling next sibling parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Sunday, 17 July 2022 at 09:23:23 UTC, Mike Parker wrote:

 `int[$]` is a sensible syntax for it. So I hope someone does 
 pick this up one day and manages to convince the right people 
 that it's worth the implementation.


If adding better inference is a point then choose a syntax that 
is more universal so that you don't end up with many different 
syntaxes for the same kind of "fill in blank" type deduction.

Btw, C++ achieves the same generically by deduction guides (or 
improved type inference) so that you can write

```
     using namespace std;

     array a{1,2,3};
```

and get the type `array<int,3>`
Jul 17 2022
next sibling parent Mike Parker <aldacron gmail.com> writes:
On Sunday, 17 July 2022 at 14:21:21 UTC, Ola Fosheim Grøstad 
wrote:

 On Sunday, 17 July 2022 at 09:23:23 UTC, Mike Parker wrote:

 `int[$]` is a sensible syntax for it. So I hope someone does 
 pick this up one day and manages to convince the right people 
 that it's worth the implementation.


 If adding better inference is a point then choose a syntax that 
 is more universal so that you don't end up with many different 
 syntaxes for the same kind of "fill in blank" type deduction.


`$` already has an association with array length, though in `a = 
[0 .. $]`. I think it's perfect for this case.
Jul 17 2022
prev sibling parent ryuukk_ <ryuukk.dev gmail.com> writes:
On Sunday, 17 July 2022 at 14:21:21 UTC, Ola Fosheim Grøstad 
wrote:

 On Sunday, 17 July 2022 at 09:23:23 UTC, Mike Parker wrote:

 `int[$]` is a sensible syntax for it. So I hope someone does 
 pick this up one day and manages to convince the right people 
 that it's worth the implementation.


 If adding better inference is a point then choose a syntax that 
 is more universal so that you don't end up with many different 
 syntaxes for the same kind of "fill in blank" type deduction.

 Btw, C++ achieves the same generically by deduction guides (or 
 improved type inference) so that you can write

 ```
     using namespace std;

     array a{1,2,3};
 ```

 and get the type `array<int,3>`


That's why i will never use C++, ever, and the reason i went with 
D instead, coming from C
Jul 17 2022
prev sibling parent reply Steven Schveighoffer <schveiguy gmail.com> writes:
On Sunday, 17 July 2022 at 09:23:23 UTC, Mike Parker wrote:


 he felt that he couldn't formulate a good case for why the 
 proposed feature was sufficiently of more benefit than 
 `staticArray` to justify the new syntax.


staticArray for nested arrays sucks:

```d
auto foo = [[1,2,3,4].staticArray,[5,6,7,8]].staticArray;
int[4][2] foo2 = [[1,2,3,4],[5,6,7,8]];
```

The second statement is much better, but you need the first to 
infer the length. Just specifying "infer the length" with a `[$]` 
on the type is a perfect fit.

You also have an issue with const conversion that's not as easy 
to specify. e.g.:

```d
char[74] foo = "this is a long string that I don't want to have 
to count the characters in";
```

Can't use staticArray here because the type will be 
`immutable(char)[74]`.

If I want to specify it should be char, I can't do 
`staticArray!char`, because then it doesn't infer anything.

I can't even cast it, because there's no way to cast without 
knowing the correct size.

This is a simple quality-of-life improvement. I think the 
original PR was reverted because it allowed too much inference, 
like:

`auto[$] foo = [1,2,3,4];`

I think just specifying the length is dependent on the length of 
the literal is enough benefit to justify the change. We don't 
need full inference of any static array type.

-Steve
Jul 17 2022
parent reply Nick Treleaven <nick geany.org> writes:
On Sunday, 17 July 2022 at 15:23:45 UTC, Steven Schveighoffer 
wrote:

 The second statement is much better, but you need the first to 
 infer the length. Just specifying "infer the length" with a 
 `[$]` on the type is a perfect fit.


There may be ambiguity with `$` for length inside an index/slice 
expression when an inferred static array type is part of an 
expression:
https://forum.dlang.org/post/qsjahatdiyxwojcwyedm forum.dlang.org


 You also have an issue with const conversion that's not as easy 
 to specify. e.g.:

 ```d
 char[74] foo = "this is a long string that I don't want to have 
 to count the characters in";
 ```


Presumably length inference would not include the terminating nul 
byte of the string literal?


 Can't use staticArray here because the type will be 
 `immutable(char)[74]`.

 If I want to specify it should be char, I can't do 
 `staticArray!char`, because then it doesn't infer anything.


Could add an overload for that:
https://forum.dlang.org/post/urzdeerfcvardyztxfab forum.dlang.org


 This is a simple quality-of-life improvement. I think the 
 original PR was reverted because it allowed too much inference, 
 like:

 `auto[$] foo = [1,2,3,4];`

 I think just specifying the length is dependent on the length 
 of the literal is enough benefit to justify the change. We 
 don't need full inference of any static array type.


Threads like these always use basic element types like int or 
char. In practice the element type can be quite complex. It's a 
pain to have to write out a complex type - e.g. `typeof(x.map!(a 
=> someExpr).front)`. That could be solved by having specific 
syntax for static array literals:

```d
auto sa = $[1,2,3,4];
```

That avoids supporting partial `auto` declarations (a reason why 
Walter didn't like that PR). It also allows inference when 
passing a literal to a template function argument where the 
parameter is not already a static array. The `$[]` syntax would 
literally mean "length array", i.e. fixed length array. (Why do 
we overload the word 'static' here for arrays?)

And it's prefix syntax, which would read well with your nested 
static array example:
```d
auto foo = $[$[1,2,3,4],[5,6,7,8]];
```

It doesn't help your `char[$] foo = "immutable data";` case 
though (which would need the staticArray overload or equivalent).
Jul 17 2022
next sibling parent reply Daniel N <no public.email> writes:
On Sunday, 17 July 2022 at 16:33:29 UTC, Nick Treleaven wrote:

 ```d
 auto sa = $[1,2,3,4];
 ```

 That avoids supporting partial `auto` declarations (a reason 
 why Walter didn't like that PR). It also allows inference when 
 passing a literal to a template function argument where the 
 parameter is not already a static array. The `$[]` syntax would 
 literally mean "length array", i.e. fixed length array. (Why do 
 we overload the word 'static' here for arrays?)


Hmm, it's not half bad!

Another idea... to enumerate all possibilities.
```d
scope sa = [1,2,3,4];
```
Jul 17 2022
parent Nick Treleaven <nick geany.org> writes:
On Sunday, 17 July 2022 at 17:23:18 UTC, Daniel N wrote:

 Another idea... to enumerate all possibilities.
 ```d
 scope sa = [1,2,3,4];
 ```


That is fine to stack-allocate dynamic array elements, but I 
think making that mean a fixed-length array would cause problems 
with typing. E.g. inferring `scope` would change the type of `sa` 
and fixed-length arrays are not ranges, etc.
Jul 18 2022
prev sibling next sibling parent Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Sunday, 17 July 2022 at 16:33:29 UTC, Nick Treleaven wrote:

 ```d
 auto sa = $[1,2,3,4];
 ```


Maybe choose something that is consistent with other literals, 
the type is generally a suffix:

"hello"c  // string
"hello"w  // wstring
"hello"d  // dstring
12345UL
Jul 17 2022
prev sibling next sibling parent reply Steven Schveighoffer <schveiguy gmail.com> writes:
On Sunday, 17 July 2022 at 16:33:29 UTC, Nick Treleaven wrote:

 On Sunday, 17 July 2022 at 15:23:45 UTC, Steven Schveighoffer 
 wrote:

 The second statement is much better, but you need the first to 
 infer the length. Just specifying "infer the length" with a 
 `[$]` on the type is a perfect fit.


 There may be ambiguity with `$` for length inside an 
 index/slice expression when an inferred static array type is 
 part of an expression:
 https://forum.dlang.org/post/qsjahatdiyxwojcwyedm forum.dlang.org


It would not be ambiguous, as `int[$]` would refer to the new 
type.

I'm having a hard time believing that kind of expression is 
currently used anywhere.

it would be consistent with using $ inside an expression of 2 
nested arrays:

```d
int[] arr;
int[] foo;

return arr[0 .. foo[$-1]]; // does $ refer to arr.length or 
foo.length?
```


 You also have an issue with const conversion that's not as 
 easy to specify. e.g.:

 ```d
 char[74] foo = "this is a long string that I don't want to 
 have to count the characters in";
 ```


 Presumably length inference would not include the terminating 
 nul byte of the string literal?


Of course, that's not actually included in the literal length. 
e.g. `"".length == 0`.


 Can't use staticArray here because the type will be 
 `immutable(char)[74]`.

 If I want to specify it should be char, I can't do 
 `staticArray!char`, because then it doesn't infer anything.


 Could add an overload for that:
 https://forum.dlang.org/post/urzdeerfcvardyztxfab forum.dlang.org


Fair point (if anything could someone create an issue on this so 
it's not forgotten?). But I still think the nested syntax isn't 
good.


 This is a simple quality-of-life improvement. I think the 
 original PR was reverted because it allowed too much 
 inference, like:

 `auto[$] foo = [1,2,3,4];`

 I think just specifying the length is dependent on the length 
 of the literal is enough benefit to justify the change. We 
 don't need full inference of any static array type.


 Threads like these always use basic element types like int or 
 char. In practice the element type can be quite complex. It's a 
 pain to have to write out a complex type - e.g. 
 `typeof(x.map!(a => someExpr).front)`.


The use case for this escapes me. You can't do this with 
staticArray anyway.

```d
auto x = arr.map!(a => a * 2).array.staticArray; // error, can't 
pass Something[] to staticArray
```

So current code that might build such a thing isn't any worse off 
with the feature.

What you need to write for this use case is a complex 
voldemort-type-producing expression, and then make multiple calls 
to that thing, inside an array expression. I just don't see it 
being a thing.


 That could be solved by having specific syntax for static array 
 literals:

 ```d
 auto sa = $[1,2,3,4];
 ```


Maybe, maybe not. Yes, without a special syntax on the right 
side, you'd need a type for it, but I don't see a really 
convincing use case for this.

That being said, I would be *ok* with this syntax, or something 
that's identified on the expression. Hell, even if it was 
`__staticArray(expr)`, that would be at least a possible solution.


 That avoids supporting partial `auto` declarations (a reason 
 why Walter didn't like that PR).


That PR discussion is... interesting. I don't know exactly what 
the rejection was, aside from "this will just release the 
floodgates of crappy feature requests".


 It also allows inference when passing a literal to a template 
 function argument where the parameter is not already a static 
 array. The `$[]` syntax would literally mean "length array", 
 i.e. fixed length array.


I'm not opposed to it exactly. But it does suffer the same 
problems as `staticArray`. It is sometimes nice to use the 
left-hand-side of the construction/assignment to determine how 
the literal is interpreted.


 (Why do we overload the word 'static' here for arrays?)


I hate that they are called "static" arrays also. 
`fixedLengthArray` is probably not a great function name though.


 And it's prefix syntax, which would read well with your nested 
 static array example:
 ```d
 auto foo = $[$[1,2,3,4],[5,6,7,8]];
 ```

 It doesn't help your `char[$] foo = "immutable data";` case 
 though (which would need the staticArray overload or 
 equivalent).


Oh yeah, agreed. Maybe something can be done about that in the 
syntax, like `$char[...]` I don't know.

-Steve
Jul 17 2022
parent Nick Treleaven <nick geany.org> writes:
On Sunday, 17 July 2022 at 20:07:37 UTC, Steven Schveighoffer 
wrote:

 On Sunday, 17 July 2022 at 16:33:29 UTC, Nick Treleaven wrote:

 There may be ambiguity with `$` for length inside an 
 index/slice expression when an inferred static array type is 
 part of an expression:
 https://forum.dlang.org/post/qsjahatdiyxwojcwyedm forum.dlang.org


 It would not be ambiguous, as `int[$]` would refer to the new 
 type.


OK, hopefully it is straightforward to implement that.


 I'm having a hard time believing that kind of expression is 
 currently used anywhere.


Probably not common, theoretically possible. The linked example 
doesn't compile. I expect it's OK to change.


 Presumably length inference would not include the terminating 
 nul byte of the string literal?


 Of course, that's not actually included in the literal length. 
 e.g. `"".length == 0`.


OK, I think that's the correct choice. It does mean `arr.ptr` 
isn't nul-terminated to pass to C, using length inference. That 
would mean people need to be careful doing that with a string 
literal and manually write the \0. Currently you have to think 
about the size of the array.

...

 The use case for this escapes me. You can't do this with 
 staticArray anyway.

 ```d
 auto x = arr.map!(a => a * 2).array.staticArray; // error, 
 can't pass Something[] to staticArray
 ```


Yes, bad example. There may be meta-programming related cases 
though, e.g.:
```d
CommonType!(mixin(someLongExpr))[$] arr = [mixin(someLongExpr)];
```
auto + fixed-length array literal would be better there. Probably 
not common though.

...

 It also allows inference when passing a literal to a template 
 function argument where the parameter is not already a static 
 array. The `$[]` syntax would literally mean "length array", 
 i.e. fixed length array.


 I'm not opposed to it exactly. But it does suffer the same 
 problems as `staticArray`.


Yes, but it doesn't need an import and is concise.


 It is sometimes nice to use the left-hand-side of the 
 construction/assignment to determine how the literal is 
 interpreted.


Yes. And if a literal is needed, one could use `cast(T[$])` 
(assuming T is simple).
Jul 18 2022
prev sibling parent reply Mike Parker <aldacron gmail.com> writes:
On Sunday, 17 July 2022 at 16:33:29 UTC, Nick Treleaven wrote:

 literally mean "length array", i.e. fixed length array. (Why do 
 we overload the word 'static' here for arrays?)


It's fairly common terminology. I couldn't tell you when it first 
came into usage, but it's used to describe fixed-length arrays in 
multiple languages.
Jul 17 2022
parent reply Mike Parker <aldacron gmail.com> writes:
On Monday, 18 July 2022 at 01:25:38 UTC, Mike Parker wrote:

 On Sunday, 17 July 2022 at 16:33:29 UTC, Nick Treleaven wrote:

 literally mean "length array", i.e. fixed length array. (Why 
 do we overload the word 'static' here for arrays?)


 It's fairly common terminology. I couldn't tell you when it 
 first came into usage, but it's used to describe fixed-length 
 arrays in multiple languages.


And I should add, I don't see it as being an overloaded usage of 
the term. Static generally means "fixed" in one form or another, 
in the sense that the properties of whatever it's applied to are 
determined prior to run time.
Jul 17 2022
parent Nick Treleaven <nick geany.org> writes:
On Monday, 18 July 2022 at 01:29:11 UTC, Mike Parker wrote:

 It's fairly common terminology. I couldn't tell you when it 
 first came into usage, but it's used to describe fixed-length 
 arrays in multiple languages.


 And I should add, I don't see it as being an overloaded usage 
 of the term. Static generally means "fixed" in one form or 
 another, in the sense that the properties of whatever it's 
 applied to are determined prior to run time.


Yes, it's not something D invented, static vs dynamic array. But 
we have so many other uses of the `static` keyword. In 
particular, `static int[] x;`, which is an array but not a static 
array! Fixed length array is clearer.
Jul 18 2022
prev sibling next sibling parent Salih Dincer <salihdb hotmail.com> writes:
On Thursday, 14 July 2022 at 13:14:59 UTC, ryuukk_ wrote:

 It is misleading, nobody expect this to be GC allocated

 It should be equal to:

 ```D
 int[3] arr = [1, 2, 3]
 ```

 Also why it is GC allocated without requiring ``new``?


`auto` is like a politician speaking with big promises. Unless 
you explicitly state it, you have to accept its choice. For 
example:

```d
void main()
{
   alias type = int[3];
   auto arr = cast(type)[1, 2, 3];
   assert(is(typeof(arr) : type));
}
```
It usually chooses int for numbers, its arrays are dynamic.

SDB 79
Jul 14 2022
prev sibling next sibling parent reply Dukc <ajieskola gmail.com> writes:
On Thursday, 14 July 2022 at 13:14:59 UTC, ryuukk_ wrote:

 It is misleading, nobody expect this to be GC allocated

 It should be equal to:

 ```D
 int[3] arr = [1, 2, 3]
 ```


TDPL book deals with this question. Andrei said that "experience 
with pascal" shows it's better to be dynamic by default.


 Also why it is GC allocated without requiring ``new``?


Otherwise it would have to be either immutable or impure. 
Consider:

```D
 safe pure int[] fun()
{ auto arr = [1, 2, 3];
   return arr;
}

 safe void main()
{ import std.stdio;
   auto arr1 = fun();
   foreach(ref el; arr1) el += 3;
   auto arr2 = fun();
   foreach(ref el; arr2) el += 10;
   arr1.writeln;
   arr2.writeln;
}
```

GC allocation is the only way this can work. If `arr` was 
allocated from static data, the two calls to `fun` would refer to 
the same array, meaning the output would be
```
[11, 12, 13]
[11, 12, 13]
```
. `fun` would not be pure at all!

`arr` in `fun` also can not be stack allocated, because stack 
allocations can last only until the function that allocated 
returns. `arr` is returned, meaning it needs to continue existing 
beyond returning from `fun`.
Jul 16 2022
parent Salih Dincer <salihdb hotmail.com> writes:
On Saturday, 16 July 2022 at 16:27:06 UTC, Dukc wrote:

 TDPL book deals with this question. Andrei said that 
 "experience with pascal" shows it's better to be dynamic by 
 default.


 Also why it is GC allocated without requiring ``new``?




Matter turns elsewhere... Are GC-controlled D arrays better, or 
static arrays recommended by traditional programmers?

On the other hand, the last example also works with static array 
because it is being copied:

```d
void main()
{
   //...

   auto foo = () => cast(int[3])[1, 2, 3];

   arr1 = foo();
   foreach(ref el; arr1) el *= 2;
   assert(arr1 == [2, 4, 6]);

   arr2 = foo();
   foreach(ref el; arr2) el *= 5;
   assert(arr2 == [5, 10, 15]);
}
```
SDB 79
Jul 16 2022
prev sibling next sibling parent Era Scarecrow <rtcvb32 yahoo.com> writes:
On Thursday, 14 July 2022 at 13:14:59 UTC, ryuukk_ wrote:

 It is misleading, nobody expect this to be GC allocated

 It should be equal to:

 ```D
 int[3] arr = [1, 2, 3]
 ```

 Also why it is GC allocated without requiring ``new``?


That would be a little confusing. If i were writing a language or 
compiler; if it was a slice/array without a known length it would 
allocate, if it is a known length or on the stack it would copy 
to the stack from a fixed immutable array in ROM, and in the case 
it's immutable it would just point to the array it would have 
copied from.

  i know enum array values would likely always be forcibly 
allocated either way.

  And static/module immutable items could point to the original 
ROM data as it would be allocated during compile-time.
Jul 16 2022
prev sibling next sibling parent reply welkam <wwwelkam gmail.com> writes:
On Thursday, 14 July 2022 at 13:14:59 UTC, ryuukk_ wrote:

 Also why it is GC allocated without requiring ``new``?


Its easier to write average code without always thinking about 
allocations. Its optimized for average coder.
Jul 16 2022
parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Saturday, 16 July 2022 at 22:44:07 UTC, welkam wrote:

 On Thursday, 14 July 2022 at 13:14:59 UTC, ryuukk_ wrote:

 Also why it is GC allocated without requiring ``new``?


 Its easier to write average code without always thinking about 
 allocations. Its optimized for average coder.


Yes, this could be done as an optimization, if people want to 
enforce it then just let them add  nogc.
Jul 16 2022
parent reply ryuukk_ <ryuukk.dev gmail.com> writes:
On Sunday, 17 July 2022 at 04:21:21 UTC, Ola Fosheim Grøstad 
wrote:

 On Saturday, 16 July 2022 at 22:44:07 UTC, welkam wrote:

 On Thursday, 14 July 2022 at 13:14:59 UTC, ryuukk_ wrote:

 Also why it is GC allocated without requiring ``new``?


 Its easier to write average code without always thinking about 
 allocations. Its optimized for average coder.


 Yes, this could be done as an optimization, if people want to 
 enforce it then just let them add  nogc.


This is why people think D is a Java++ and is a GC'd language

Let's enforce this sentiment, and cement it so nothing can 
improve moving forward, never reflect, always double down

That's concerning


 The focus should be on things that matters, more special syntax 
 is not a net positive.
 New features ought to be more generic, like deduction guides in 
 C++.


I agree with that, some other features are more important, it is 
not urgent, but still is something that should be handled without 
suggesting importing modules and without writing template soup


 Nothing prevents you from creating your own 
 ‘mkarray!char(1,2,3,4)’?


I'm not sure if you are being serious or not

Why `1+1`? why not

```D
import std.math;
add(1, 1):
```

Why `do_something(1)`? why not

```D
import std.function;
call_function( do_something ).with_arg(1);
```

why `array[1] == 'c'`? why not

```D
import std.array;
contains(array, 1, 'c');
```

User should be suggested to write code to solve the problem he is 
trying to solve in his program

Not suggesting to write code to fix the deficiencies of the 
language

That is why people come up with new languages; and that messages 
is what's pushing people to choose alternatives
Jul 17 2022
parent Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Sunday, 17 July 2022 at 14:43:01 UTC, ryuukk_ wrote:

 On Sunday, 17 July 2022 at 04:21:21 UTC, Ola Fosheim Grøstad 
 wrote:

 Yes, this could be done as an optimization, if people want to 
 enforce it then just let them add  nogc.


 This is why people think D is a Java++ and is a GC'd language

 Let's enforce this sentiment, and cement it so nothing can 
 improve moving forward, never reflect, always double down


No, C and C++ are completely stuck in being overspecific, which 
makes them time consuming languages to deal with, but a good 
language will allow you to express intent and let the compiler 
select the best performing implementation.

This makes much more sense for generic programming. You want to 
write one implementation and let the compiler adapt the 
implementation through optimization where it is trivial to do so.

What is concerning is that D has not improved on templates and 
now C++ is becoming as convenient for library development if not 
more so...



 Nothing prevents you from creating your own 
 ‘mkarray!char(1,2,3,4)’?


 I'm not sure if you are being serious or not


The idiomatic C++20 way is similar `to_array<char>({1,2,3,4})`. I 
don't see the big deal.

D needs to stop trying to drive in individual nails with special 
casing and figure out the big picture.
Jul 17 2022
prev sibling next sibling parent reply FeepingCreature <feepingcreature gmail.com> writes:
On Thursday, 14 July 2022 at 13:14:59 UTC, ryuukk_ wrote:

 It is misleading, nobody expect this to be GC allocated

 It should be equal to:

 ```D
 int[3] arr = [1, 2, 3]
 ```

 Also why it is GC allocated without requiring ``new``?


DMD 2.099 has introduced crippling bugs that arise from 
overzealous stack allocation. If I could have a command line 
switch that would always heap allocate everything not *completely 
obviously* a stack allocation, ie. always heap allocate closures, 
always heap allocate arrays, I would put it in our build scripts 
and never touch it again.

Stack allocation without extremely reliable escape analysis is an 
express ride to corruptiontown. And D does not have extremely 
reliable escape analysis.
Jul 18 2022
next sibling parent reply Nick Treleaven <nick geany.org> writes:
On Monday, 18 July 2022 at 12:13:47 UTC, FeepingCreature wrote:

 And D does not have extremely reliable escape analysis.


Can you please post an example of  safe -dip1000 code that allows 
memory corruption? (There is a known problem with constructors 
with a PR to fix).

Also I presume the bugs you're talking about aren't just due to 
the `in` preview switch?
Jul 18 2022
parent reply FeepingCreature <feepingcreature gmail.com> writes:
On Monday, 18 July 2022 at 16:19:20 UTC, Nick Treleaven wrote:

 On Monday, 18 July 2022 at 12:13:47 UTC, FeepingCreature wrote:

 And D does not have extremely reliable escape analysis.


 Can you please post an example of  safe -dip1000 code that 
 allows memory corruption? (There is a known problem with 
 constructors with a PR to fix).

 Also I presume the bugs you're talking about aren't just due to 
 the `in` preview switch?


Why would I post an example of dip1000? dip1000 is not the 
default. If the compiler needs dip1000 to work correctly, that 
means the compiler is not working correctly.

The bug that triggered this is 
https://issues.dlang.org/show_bug.cgi?id=23170 , thankfully 
already fixed. I'm not optimistic it's the last one though.

DIP1000 is good, but if memory corruption in non-DIP1000 compiles 
is the cost of the transition, then the transition is being 
mishandled. Spurious compiler errors, fine, but a compiler update 
should not cause a very basic construct like [] to start 
corrupting values.
Jul 18 2022
parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Monday, 18 July 2022 at 17:45:08 UTC, FeepingCreature wrote:

 Spurious compiler errors, fine, but a compiler update should 
 not cause a very basic construct like [] to start corrupting 
 values.


But this is more of a development process and quality assurance 
issue than a language design issue.

The former should adapt to the latter, not the other way around…
Jul 18 2022
parent reply Hipreme <msnmancini hotmail.com> writes:
On Monday, 18 July 2022 at 18:01:45 UTC, Ola Fosheim Grøstad 
wrote:

 On Monday, 18 July 2022 at 17:45:08 UTC, FeepingCreature wrote:

 Spurious compiler errors, fine, but a compiler update should 
 not cause a very basic construct like [] to start corrupting 
 values.


 But this is more of a development process and quality assurance 
 issue than a language design issue.

 The former should adapt to the latter, not the other way around…



I have made a Renderer abstraction, so, in OpenGL terms I have 
been setting my Uniform variables such as `Vector2`, `Vector3`, 
`Vector4`. But importing `math.vector` for just setting those 
variables creates unnecessary dependency, what have I done to 
solve this problem?

```d
void setUniform(string uniformName, float[2] vec);
void setUniform(string uniformName, float[3] vec);
void setUniform(string uniformName, float[4] vec);
```

What happens if I do:
```d
void setupRenderer()  nogc
{
     setUniform("Test", [1, 2]);
     setUniform("Test", [1, 2, 3]);
     setUniform("Test", [1, 2, 3, 4]);
}
```

Then what it happens?
Error: ` nogc` function `setupRenderer` cannot call non- nogc 
function `renderer.setUniform`
Error: ` nogc` function `setupRenderer` cannot call non- nogc 
function `renderer.setUniform`
Error: ` nogc` function `setupRenderer` cannot call non- nogc 
function `renderer.setUniform`


You guys solution:

```d
import std.array;
void setupRenderer()  nogc
{
     setUniform("Test", [1, 2].staticArray);
     setUniform("Test", [1, 2, 3].staticArray);
     setUniform("Test", [1, 2, 3, 4].staticArray);
}
```

Unnecessary verbosity. That's all I could say. Then, what happens?

```
onlineapp.d(29): Error: none of the overloads of `setUniform` are 
callable using argument types `(string, int[2])`
onlineapp.d(13):        Candidates are: 
`onlineapp.setUniform(string uniformName, float[2] vec)`
onlineapp.d(17):                        
`onlineapp.setUniform(string uniformName, float[3] vec)`
onlineapp.d(21):                        
`onlineapp.setUniform(string uniformName, float[4] vec)`
onlineapp.d(30): Error: none of the overloads of `setUniform` are 
callable using argument types `(string, int[3])`
onlineapp.d(13):        Candidates are: 
`onlineapp.setUniform(string uniformName, float[2] vec)`
onlineapp.d(17):                        
`onlineapp.setUniform(string uniformName, float[3] vec)`
onlineapp.d(21):                        
`onlineapp.setUniform(string uniformName, float[4] vec)`
onlineapp.d(31): Error: none of the overloads of `setUniform` are 
callable using argument types `(string, int[4])`
onlineapp.d(13):        Candidates are: 
`onlineapp.setUniform(string uniformName, float[2] vec)`
onlineapp.d(17):                        
`onlineapp.setUniform(string uniformName, float[3] vec)`
onlineapp.d(21):
```

So, for solving that, one must either:

`setUniform("Test", [cast(float)1, 2].staticArray);`
Or they need to actually have a float literal in the array.

Actually, I think that could be one of the the worse usecases for 
that
Jul 19 2022
next sibling parent reply FeepingCreature <feepingcreature gmail.com> writes:
On Tuesday, 19 July 2022 at 11:00:58 UTC, Hipreme wrote:

 What happens if I do:
 ```d
 void setupRenderer()  nogc
 {
     setUniform("Test", [1, 2]);
     setUniform("Test", [1, 2, 3]);
     setUniform("Test", [1, 2, 3, 4]);
 }
 ```

 Then what it happens?
 Error: ` nogc` function `setupRenderer` cannot call non- nogc 
 function `renderer.setUniform`
 Error: ` nogc` function `setupRenderer` cannot call non- nogc 
 function `renderer.setUniform`
 Error: ` nogc` function `setupRenderer` cannot call non- nogc 
 function `renderer.setUniform`



...



 So, for solving that, one must either:

 `setUniform("Test", [cast(float)1, 2].staticArray);`
 Or they need to actually have a float literal in the array.

 Actually, I think that could be one of the the worse usecases 
 for that


Just to note, even without DIP1000 you can just

void setUniform(string name, float[] vec...) { }

setUniform("Test", 1, 2);

and get a stack allocation for vec.

But what I'd do if I wanted to make fully sure is just `void 
setUniform(T...)(string name, T args)` and then build a static 
buffer manually inside `setUniform`.
Jul 19 2022
parent ryuukk_ <ryuukk.dev gmail.com> writes:
On Tuesday, 19 July 2022 at 11:19:10 UTC, FeepingCreature wrote:

 On Tuesday, 19 July 2022 at 11:00:58 UTC, Hipreme wrote:

 What happens if I do:
 ```d
 void setupRenderer()  nogc
 {
     setUniform("Test", [1, 2]);
     setUniform("Test", [1, 2, 3]);
     setUniform("Test", [1, 2, 3, 4]);
 }
 ```

 Then what it happens?
 Error: ` nogc` function `setupRenderer` cannot call non- nogc 
 function `renderer.setUniform`
 Error: ` nogc` function `setupRenderer` cannot call non- nogc 
 function `renderer.setUniform`
 Error: ` nogc` function `setupRenderer` cannot call non- nogc 
 function `renderer.setUniform`



...



 So, for solving that, one must either:

 `setUniform("Test", [cast(float)1, 2].staticArray);`
 Or they need to actually have a float literal in the array.

 Actually, I think that could be one of the the worse usecases 
 for that


 Just to note, even without DIP1000 you can just

 void setUniform(string name, float[] vec...) { }

 setUniform("Test", 1, 2);

 and get a stack allocation for vec.

 But what I'd do if I wanted to make fully sure is just `void 
 setUniform(T...)(string name, T args)` and then build a static 
 buffer manually inside `setUniform`.



I don't think that approach is good

I personally use:

```D
void setUniform(string name, scope float[] data);
```

Clearer about what the data is, will always stack alloc and will 
be able to take what ever slice you throw at it

No need vararg or tempaltes that'll end up slowing down your 
compile speed
Jul 19 2022
prev sibling next sibling parent Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Tuesday, 19 July 2022 at 11:00:58 UTC, Hipreme wrote:

 ```d
 void setUniform(string uniformName, float[2] vec);
 void setUniform(string uniformName, float[3] vec);
 void setUniform(string uniformName, float[4] vec);
 ```

 What happens if I do:
 ```d
 void setupRenderer()  nogc
 {
     setUniform("Test", [1, 2]);
     setUniform("Test", [1, 2, 3]);
     setUniform("Test", [1, 2, 3, 4]);
 }
 ```

 Then what it happens?
 Error: ` nogc` function `setupRenderer` cannot call non- nogc 
 function `renderer.setUniform`
 Error: ` nogc` function `setupRenderer` cannot call non- nogc 
 function `renderer.setUniform`
 Error: ` nogc` function `setupRenderer` cannot call non- nogc 
 function `renderer.setUniform`


I don't understand the issue, this works?

```
import std;
float[2] a;
void setUniform(string uniformName, float[2] vec) nogc { a = vec;}

void setupRenderer()  nogc
{
     setUniform("Test", [1, 2]);
}
void main()
{
    setupRenderer();
    writeln(a);
}
```
Jul 19 2022
prev sibling parent Steven Schveighoffer <schveiguy gmail.com> writes:
On Tuesday, 19 July 2022 at 11:00:58 UTC, Hipreme wrote:


 ```d
 void setUniform(string uniformName, float[2] vec);
 void setUniform(string uniformName, float[3] vec);
 void setUniform(string uniformName, float[4] vec);
 ```

 What happens if I do:
 ```d
 void setupRenderer()  nogc
 {
     setUniform("Test", [1, 2]);
     setUniform("Test", [1, 2, 3]);
     setUniform("Test", [1, 2, 3, 4]);
 }
 ```

 Then what it happens?
 Error: ` nogc` function `setupRenderer` cannot call non- nogc 
 function `renderer.setUniform`
 Error: ` nogc` function `setupRenderer` cannot call non- nogc 
 function `renderer.setUniform`
 Error: ` nogc` function `setupRenderer` cannot call non- nogc 
 function `renderer.setUniform`


Note how this is not complaining about the allocation of the 
array in `setupRenderer`, it's complaining about `setUniform`

if `setUniform` is truly ` nogc`, properly add the attribute and 
it will work.

-Steve
Jul 19 2022
prev sibling next sibling parent reply ryuukk_ <ryuukk.dev gmail.com> writes:
On Monday, 18 July 2022 at 12:13:47 UTC, FeepingCreature wrote:

 On Thursday, 14 July 2022 at 13:14:59 UTC, ryuukk_ wrote:

 It is misleading, nobody expect this to be GC allocated

 It should be equal to:

 ```D
 int[3] arr = [1, 2, 3]
 ```

 Also why it is GC allocated without requiring ``new``?


 DMD 2.099 has introduced crippling bugs that arise from 
 overzealous stack allocation. If I could have a command line 
 switch that would always heap allocate everything not 
 *completely obviously* a stack allocation, ie. always heap 
 allocate closures, always heap allocate arrays, I would put it 
 in our build scripts and never touch it again.

 Stack allocation without extremely reliable escape analysis is 
 an express ride to corruptiontown. And D does not have 
 extremely reliable escape analysis.



If stack allocation is removed and everything will be heap 
allocated, then it will be the day i get rid of D

If compilers bugs there are, they should be fixed

I don't understand why you even make that suggestion, a language 
without stack allocation can't be taken seriously
Jul 19 2022
parent FeepingCreature <feepingcreature gmail.com> writes:
On Tuesday, 19 July 2022 at 11:54:17 UTC, ryuukk_ wrote:

 If stack allocation is removed and everything will be heap 
 allocated, then it will be the day i get rid of D

 If compilers bugs there are, they should be fixed

 I don't understand why you even make that suggestion, a 
 language without stack allocation can't be taken seriously


Different usecases. To be clear, my take is that things should be 
stack allocated exactly iff they are value types. (By preference, 
immutable value types.) And heap allocated iff they're reference 
types. Arrays are reference types, so they should be heap 
allocated. Objects ditto. Simple and predictable. I just don't 
see the advantage in cleverly stack allocating arrays; it seems 
like an invitation to danger that's not worth the benefit. If you 
want a stack allocated fixed-size list, you should use an idiom 
that always stack allocates it, but also reliably copies it to 
callers and protects it from unintentional mutation. Stack 
allocating T[] overloads the abstraction, IMO.
Jul 19 2022
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 7/18/2022 5:13 AM, FeepingCreature wrote:

 Stack allocation without extremely reliable escape analysis is an express ride 
 to corruptiontown. And D does not have extremely reliable escape analysis.


I have submitted open PRs to fix the known problems with it.
Jul 19 2022
parent FeepingCreature <feepingcreature gmail.com> writes:
On Tuesday, 19 July 2022 at 17:44:29 UTC, Walter Bright wrote:

 On 7/18/2022 5:13 AM, FeepingCreature wrote:

 Stack allocation without extremely reliable escape analysis is 
 an express ride to corruptiontown. And D does not have 
 extremely reliable escape analysis.


 I have submitted open PRs to fix the known problems with it.


No yes, I know, and I'm not complaining per se. I'm just saying 
that I, personally, writing for a corporate usecase, would very 
gladly sacrifice a bit of performance for having confidence that 
I won't update the compiler and suddenly instead of version 1.0 a 
service sometimes chooses to report its version as -376789630.0. 
(To pick an example that was luckily caught in testing.)

New, even false, compiler errors and breaking libraries is 
completely fine with me. Deprecations: completely fine. 
Regression miscompilations, however, are the stuff that 
nightmares are made of. After all, compiler errors annoy 
developers; with a bit of bad luck, miscompilations annoy 
customers.
Jul 20 2022
prev sibling next sibling parent reply Quirin Schroll <qs.il.paperinik gmail.com> writes:
On Thursday, 14 July 2022 at 13:14:59 UTC, ryuukk_ wrote:

 It is misleading, nobody expect this to be GC allocated

 It should be equal to:

 ```D
 int[3] arr = [1, 2, 3]
 ```

 Also why it is GC allocated without requiring ``new``?


Because it’s useful to more people than if it were the opposite. 
If you find that `staticArray` too verbose, there’s a 
single-keystroke way to get pseudo-literals for static arrays:

```D
struct s
{
     static typeof([ Ts.init ][0])[Ts.length] opIndex(Ts...)(auto 
ref Ts args)
     {
         import std.functional : forward;
         return [ forward!args ];
     }
}
```
Usage:
```D
void main()
{
     auto empty = s[];
     static assert(is(typeof(empty) == void[0]));

     auto xs = s[1,cast(byte)2,3];
     static assert(is(typeof(xs) == int[3]));

     static struct NoCopy {  disable this(this); }
     auto noCopies = s[NoCopy(), NoCopy()];
}
```
You’re free to choose any name (except keywords). If you name it
Jul 19 2022
next sibling parent FeepingCreature <feepingcreature gmail.com> writes:
On Tuesday, 19 July 2022 at 14:04:09 UTC, Quirin Schroll wrote:

 ```D
 void main()
 {
     auto empty = s[];
     static assert(is(typeof(empty) == void[0]));

     auto xs = s[1,cast(byte)2,3];
     static assert(is(typeof(xs) == int[3]));

     static struct NoCopy {  disable this(this); }
     auto noCopies = s[NoCopy(), NoCopy()];
 }
 ```
 You’re free to choose any name (except keywords). If you name 



I love this! Great use of multidimensional indexes. I guess you 
can think of it as `s` being an n-dimensional table of all static 
arrays.
Jul 19 2022
prev sibling parent reply ryuukk_ <ryuukk.dev gmail.com> writes:
On Tuesday, 19 July 2022 at 14:04:09 UTC, Quirin Schroll wrote:

 On Thursday, 14 July 2022 at 13:14:59 UTC, ryuukk_ wrote:

 It is misleading, nobody expect this to be GC allocated

 It should be equal to:

 ```D
 int[3] arr = [1, 2, 3]
 ```

 Also why it is GC allocated without requiring ``new``?


 Because it’s useful to more people than if it were the 
 opposite. If you find that `staticArray` too verbose, there’s a 
 single-keystroke way to get pseudo-literals for static arrays:

 ```D
 struct s
 {
     static typeof([ Ts.init ][0])[Ts.length] 
 opIndex(Ts...)(auto ref Ts args)
     {
         import std.functional : forward;
         return [ forward!args ];
     }
 }
 ```
 Usage:
 ```D
 void main()
 {
     auto empty = s[];
     static assert(is(typeof(empty) == void[0]));

     auto xs = s[1,cast(byte)2,3];
     static assert(is(typeof(xs) == int[3]));

     static struct NoCopy {  disable this(this); }
     auto noCopies = s[NoCopy(), NoCopy()];
 }
 ```
 You’re free to choose any name (except keywords). If you name 




That's not the point..

The difference between:

- having to write the helper code
- having to tap into the std
- having then to import this helper module everywhere
- having to spend time doing all of the above and carry that file 
in all my projects

vs


some other languages

For something as basic as wanting an inferred fixed static array 
length

So the language can help me so i don't have to manually count how 
many elements are in there: `auto arr = 
[1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1];`

Let's stick with C then, why bother coming up with a better 
language?

Same with Tagged Union, same with Tuple, same with Nullable

And then it always end up in these endless discussion where one 
has to constantly remind people this simple fact, and then he 
feels demotivated, and then withdraw his suggestion, and then 
gets interested in an other language instead

I'm not a compiler/language developer, i am a language user, 
little things like that makes the difference
Jul 19 2022
parent reply jfondren <julian.fondren gmail.com> writes:
On Tuesday, 19 July 2022 at 15:27:57 UTC, ryuukk_ wrote:

 - having to write the helper code
 - having to tap into the std
 - having then to import this helper module everywhere
 - having to spend time doing all of the above and carry that 
 file in all my projects


...

 For something as basic as wanting an inferred fixed static 
 array length


"This is basic" isn't that persuasive, and realistically the 
solution isn't all of that but just "import the improved template 
and then use it".

Try these:

- D should be at *least* as convenient as C. Here, it is clearly 
worse.

- D should retain an advantage of fast compilation. 
Microbenchmarks easily show that compilation is slower with this 
template (and results in larger objects--larger with each 
different length and type of array).

- Do you really want someone to think about a choice like this? 
Between tediously counting the members of static arrays, or 
having faster and slimmer builds? Do you want to see a D style 
guide with such a suggestion in it?
Jul 19 2022
parent reply ryuukk_ <ryuukk.dev gmail.com> writes:
On Tuesday, 19 July 2022 at 16:25:03 UTC, jfondren wrote:

 On Tuesday, 19 July 2022 at 15:27:57 UTC, ryuukk_ wrote:

 - having to write the helper code
 - having to tap into the std
 - having then to import this helper module everywhere
 - having to spend time doing all of the above and carry that 
 file in all my projects


 ...

 For something as basic as wanting an inferred fixed static 
 array length


 "This is basic" isn't that persuasive, and realistically the 
 solution isn't all of that but just "import the improved 
 template and then use it".

 Try these:

 - D should be at *least* as convenient as C. Here, it is 
 clearly worse.

 - D should retain an advantage of fast compilation. 
 Microbenchmarks easily show that compilation is slower with 
 this template (and results in larger objects--larger with each 
 different length and type of array).

 - Do you really want someone to think about a choice like this? 
 Between tediously counting the members of static arrays, or 
 having faster and slimmer builds? Do you want to see a D style 
 guide with such a suggestion in it?


Of course, that is why i referred to "template soup" when talking 
about std.sumtype instead of built in tagged union, in the other 
post

But i am afraid of pointing out too many things will make me 
sound too negative and just getting ignored as a result, it is 
tiring to constantly have to remind everything, so i tend to just 
rush unfortunately
Jul 19 2022
parent reply Don Allen <donaldcallen gmail.com> writes:
Personally, I hope Walter ignores this conversation. I think the 
current syntactic distinction (presence or absence of a constant 
length) between static and dynamic arrays is fine and whether a 
dynamic array is gc-allocated or stack-allocated seems to me to 
be a compiler optimization issue. I would think that if the 
compiler can prove that the array doesn't need to be re-allocated 
due to expansion and if allocation on the stack provides a 
sufficient lifetime, then it can stack allocate. And we should 
only care whether dmd does this optimization if it becomes clear 
that it is important in a lot of use cases, which I doubt.

And regarding that optimization, as hardware has gotten faster 
and faster (remember the Cray 1 "supercomputer"? It had an 80 mhz 
clock frequency), we have become more and more guilty of 
premature optimization. The flip side of that is that is the 
amount of software we all use daily that is written in languages 
like Python, Javascript or PHP that are perhaps 2 orders of 
magnitude slower than D and still provide adequate performance 
even on our phones.

My opinion.

/Don
Jul 23 2022
next sibling parent Salih Dincer <salihdb hotmail.com> writes:
On Saturday, 23 July 2022 at 14:56:48 UTC, Don Allen wrote:

 Personally, I hope Walter ignores this conversation. I think 
 the current syntactic distinction (presence or absence of a 
 constant length) between static and dynamic arrays is fine and 
 whether a dynamic array is gc-allocated or stack-allocated 
 seems to me to be a compiler optimization issue. I would think 
 that if the compiler can prove that the array doesn't need to 
 be re-allocated due to expansion  [...]


I think Walter will give us a satisfactory explanation on this.

SDB 79
Jul 23 2022
prev sibling parent reply ryuukk_ <ryuukk.dev gmail.com> writes:
On Saturday, 23 July 2022 at 14:56:48 UTC, Don Allen wrote:

 Personally, I hope Walter ignores this conversation. I think 
 the current syntactic distinction (presence or absence of a 
 constant length) between static and dynamic arrays is fine and 
 whether a dynamic array is gc-allocated or stack-allocated 
 seems to me to be a compiler optimization issue. I would think 
 that if the compiler can prove that the array doesn't need to 
 be re-allocated due to expansion and if allocation on the stack 
 provides a sufficient lifetime, then it can stack allocate. And 
 we should only care whether dmd does this optimization if it 
 becomes clear that it is important in a lot of use cases, which 
 I doubt.


I would be fine if the distinction was made by the compiler, but 
in critical performance scenarios, i don't want to gamble wether 
the compiler will optimize something or not

I want to make sure that my intent is perfectly understood by the 
compiler

I don't want any ambiguity, when i write the code, and more 
importantly when i read it

"Oh it is `auto arr = [1, 2, 3]` will it be stack allocated? hmm 
idk, let me decypher this whole algorithm again`"


 And regarding that optimization, as hardware has gotten faster 
 and faster (remember the Cray 1 "supercomputer"? It had an 80 
 mhz clock frequency), we have become more and more guilty of 
 premature optimization. The flip side of that is that is the 
 amount of software we all use daily that is written in 
 languages like Python, Javascript or PHP that are perhaps 2 
 orders of magnitude slower than D and still provide adequate 
 performance even on our phones.

 My opinion.

 /Don


Not everyone develop for High End devices

Some people are fine paying more $$$ for higher Cloud instance 
tier, some are not

I personally stick to the cheapest to host my stuff, and my care 
made me save lot of money, and my programs are all fast, no 
compromise, and the language shouldn't cater to the lower common 
denominator, the developer should make that choice
Jul 23 2022
parent reply Don Allen <donaldcallen gmail.com> writes:
On Saturday, 23 July 2022 at 15:09:11 UTC, ryuukk_ wrote:

 On Saturday, 23 July 2022 at 14:56:48 UTC, Don Allen wrote:

 Personally, I hope Walter ignores this conversation. I think 
 the current syntactic distinction (presence or absence of a 
 constant length) between static and dynamic arrays is fine and 
 whether a dynamic array is gc-allocated or stack-allocated 
 seems to me to be a compiler optimization issue. I would think 
 that if the compiler can prove that the array doesn't need to 
 be re-allocated due to expansion and if allocation on the 
 stack provides a sufficient lifetime, then it can stack 
 allocate. And we should only care whether dmd does this 
 optimization if it becomes clear that it is important in a lot 
 of use cases, which I doubt.


 I would be fine if the distinction was made by the compiler, 
 but in critical performance scenarios, i don't want to gamble 
 wether the compiler will optimize something or not

 I want to make sure that my intent is perfectly understood by 
 the compiler

 I don't want any ambiguity, when i write the code, and more 
 importantly when i read it

 "Oh it is `auto arr = [1, 2, 3]` will it be stack allocated? 
 hmm idk, let me decypher this whole algorithm again`"


If you don't want any ambiguity and want to be sure your array is 
stack-allocated, then
say so explicitly
````
int arr[3]={1,2,3}
````

rather than using auto.

 And regarding that optimization, as hardware has gotten faster 
 and faster (remember the Cray 1 "supercomputer"? It had an 80 
 mhz clock frequency), we have become more and more guilty of 
 premature optimization. The flip side of that is that is the 
 amount of software we all use daily that is written in 
 languages like Python, Javascript or PHP that are perhaps 2 
 orders of magnitude slower than D and still provide adequate 
 performance even on our phones.

 My opinion.

 /Don


 Not everyone develop for High End devices

 Some people are fine paying more $$$ for higher Cloud instance 
 tier, some are not

 I personally stick to the cheapest to host my stuff, and my 
 care made me save lot of money, and my programs are all fast, 
 no compromise, and the language shouldn't cater to the lower 
 common denominator, the developer should make that choice


And the developer *can* make that choice as the language stands 
today.

As for the gc-allocated vs static optimization, that only applies 
to dynamic arrays and, as I said, it is far from clear how 
important that is in the grand scheme of things, even on cheap 
hardware. But if it's important to you that your arrays be 
stack-allocated, use static arrays, specified explicitly (not by 
using 'auto). And if passing by value is a problem for you, pass 
pointers. What you want is in the language now.
Jul 23 2022
parent reply ryuukk_ <ryuukk.dev gmail.com> writes:
On Saturday, 23 July 2022 at 17:37:04 UTC, Don Allen wrote:

 On Saturday, 23 July 2022 at 15:09:11 UTC, ryuukk_ wrote:

 On Saturday, 23 July 2022 at 14:56:48 UTC, Don Allen wrote:

 Personally, I hope Walter ignores this conversation. I think 
 the current syntactic distinction (presence or absence of a 
 constant length) between static and dynamic arrays is fine 
 and whether a dynamic array is gc-allocated or 
 stack-allocated seems to me to be a compiler optimization 
 issue. I would think that if the compiler can prove that the 
 array doesn't need to be re-allocated due to expansion and if 
 allocation on the stack provides a sufficient lifetime, then 
 it can stack allocate. And we should only care whether dmd 
 does this optimization if it becomes clear that it is 
 important in a lot of use cases, which I doubt.


 I would be fine if the distinction was made by the compiler, 
 but in critical performance scenarios, i don't want to gamble 
 wether the compiler will optimize something or not

 I want to make sure that my intent is perfectly understood by 
 the compiler

 I don't want any ambiguity, when i write the code, and more 
 importantly when i read it

 "Oh it is `auto arr = [1, 2, 3]` will it be stack allocated? 
 hmm idk, let me decypher this whole algorithm again`"


 If you don't want any ambiguity and want to be sure your array 
 is stack-allocated, then
 say so explicitly
 ````
 int arr[3]={1,2,3}
 ````

 rather than using auto.

 And regarding that optimization, as hardware has gotten 
 faster and faster (remember the Cray 1 "supercomputer"? It 
 had an 80 mhz clock frequency), we have become more and more 
 guilty of premature optimization. The flip side of that is 
 that is the amount of software we all use daily that is 
 written in languages like Python, Javascript or PHP that are 
 perhaps 2 orders of magnitude slower than D and still provide 
 adequate performance even on our phones.

 My opinion.

 /Don


 Not everyone develop for High End devices

 Some people are fine paying more $$$ for higher Cloud instance 
 tier, some are not

 I personally stick to the cheapest to host my stuff, and my 
 care made me save lot of money, and my programs are all fast, 
 no compromise, and the language shouldn't cater to the lower 
 common denominator, the developer should make that choice


 And the developer *can* make that choice as the language stands 
 today.

 As for the gc-allocated vs static optimization, that only 
 applies to dynamic arrays and, as I said, it is far from clear 
 how important that is in the grand scheme of things, even on 
 cheap hardware. But if it's important to you that your arrays 
 be stack-allocated, use static arrays, specified explicitly 
 (not by using 'auto). And if passing by value is a problem for 
 you, pass pointers. What you want is in the language now.



I'm not asking how to write a static array in D, i'm asking to 
improve how we write them

I suggest you check the motive in the DIP 
https://github.com/dlang/DIPs/blob/master/DIPs/other/DIP1039.md
Jul 23 2022
parent Don Allen <donaldcallen gmail.com> writes:
On Saturday, 23 July 2022 at 17:51:34 UTC, ryuukk_ wrote:

 On Saturday, 23 July 2022 at 17:37:04 UTC, Don Allen wrote:

 On Saturday, 23 July 2022 at 15:09:11 UTC, ryuukk_ wrote:

 On Saturday, 23 July 2022 at 14:56:48 UTC, Don Allen wrote:

 Personally, I hope Walter ignores this conversation. I think 
 the current syntactic distinction (presence or absence of a 
 constant length) between static and dynamic arrays is fine 
 and whether a dynamic array is gc-allocated or 
 stack-allocated seems to me to be a compiler optimization 
 issue. I would think that if the compiler can prove that the 
 array doesn't need to be re-allocated due to expansion and 
 if allocation on the stack provides a sufficient lifetime, 
 then it can stack allocate. And we should only care whether 
 dmd does this optimization if it becomes clear that it is 
 important in a lot of use cases, which I doubt.


 I would be fine if the distinction was made by the compiler, 
 but in critical performance scenarios, i don't want to gamble 
 wether the compiler will optimize something or not

 I want to make sure that my intent is perfectly understood by 
 the compiler

 I don't want any ambiguity, when i write the code, and more 
 importantly when i read it

 "Oh it is `auto arr = [1, 2, 3]` will it be stack allocated? 
 hmm idk, let me decypher this whole algorithm again`"


 If you don't want any ambiguity and want to be sure your array 
 is stack-allocated, then
 say so explicitly
 ````
 int arr[3]={1,2,3}
 ````

 rather than using auto.

 And regarding that optimization, as hardware has gotten 
 faster and faster (remember the Cray 1 "supercomputer"? It 
 had an 80 mhz clock frequency), we have become more and more 
 guilty of premature optimization. The flip side of that is 
 that is the amount of software we all use daily that is 
 written in languages like Python, Javascript or PHP that are 
 perhaps 2 orders of magnitude slower than D and still 
 provide adequate performance even on our phones.

 My opinion.

 /Don


 Not everyone develop for High End devices

 Some people are fine paying more $$$ for higher Cloud 
 instance tier, some are not

 I personally stick to the cheapest to host my stuff, and my 
 care made me save lot of money, and my programs are all fast, 
 no compromise, and the language shouldn't cater to the lower 
 common denominator, the developer should make that choice


 And the developer *can* make that choice as the language 
 stands today.

 As for the gc-allocated vs static optimization, that only 
 applies to dynamic arrays and, as I said, it is far from clear 
 how important that is in the grand scheme of things, even on 
 cheap hardware. But if it's important to you that your arrays 
 be stack-allocated, use static arrays, specified explicitly 
 (not by using 'auto). And if passing by value is a problem for 
 you, pass pointers. What you want is in the language now.



 I'm not asking how to write a static array in D, i'm asking to 
 improve how we write them

 I suggest you check the motive in the DIP 
 https://github.com/dlang/DIPs/blob/master/DIPs/other/DIP1039.md


I'm aware of that. And I think what is being suggested is trivial 
syntactic sugar that fixes something that ain't broke.
Jul 23 2022
prev sibling next sibling parent Siarhei Siamashka <siarhei.siamashka gmail.com> writes:
On Thursday, 14 July 2022 at 13:14:59 UTC, ryuukk_ wrote:

 It is misleading, nobody expect this to be GC allocated

 It should be equal to:

 ```D
 int[3] arr = [1, 2, 3]
 ```

 Also why it is GC allocated without requiring ``new``?


It is not always GC allocated. LDC optimizer can remove GC 
allocation in the following code (unless such optimization is 
disabled by --disable-gc2stack option):
```D
auto foo()
{
     auto arr = [1, 2, 3];
     return arr[0] + arr[1];
}
```
https://godbolt.org/z/PWTzEbsW8
Jul 19 2022
prev sibling parent reply Dave P. <dave287091 gmail.com> writes:
On Thursday, 14 July 2022 at 13:14:59 UTC, ryuukk_ wrote:

 It is misleading, nobody expect this to be GC allocated

 It should be equal to:

 ```D
 int[3] arr = [1, 2, 3]
 ```

 Also why it is GC allocated without requiring ``new``?


Perhaps `scope` could be reused to mean the same thing?

```D
scope arr = [1,2,3]; // guaranteed to be stack-allocated
```
Jul 23 2022
parent Nick Treleaven <nick geany.org> writes:
On Saturday, 23 July 2022 at 18:41:20 UTC, Dave P. wrote:

 Perhaps `scope` could be reused to mean the same thing?

 ```D
 scope arr = [1,2,3]; // guaranteed to be stack-allocated
 ```


Then arr is not a static array, it's a slice. See:
https://forum.dlang.org/post/jomlqltebzeambvwfrxp forum.dlang.org
Jul 25 2022