www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Array literals are weird.

reply Blatnik <blatblatnik gmail.com> writes:
I love how D redesigned the terrible C/C++ arrays. And it's 
awesome that array operations like element wise +, -, etc. are 
built into the language - it makes me want to use arrays and 
slices for everything. But there are still some rough edges in 
the design.

What do you expect to happen when you run this:

```D
import std;
void main() {
   writeln(typeid([1, 2, 3]));
}
```

Maybe I'm crazy, but I would expect `int[3]` to be printed. But 
`int[]` gets printed instead.

Why? What's the reason for this design?

This automatic downconversion loses potentially useful type 
information by default. It also means lazy code like this:

```D
auto array = [1, 2, 3]; // Type deduced as int[], not int[3]
```

performs an allocation, and thus it can't be used in  nogc or 
-betterC. (Not to mention that it's a completely unnecessary 
memory allocation).

It also means that functions that take a slice parameter:

```D
void foo(int[] bar);
```

Can't be called naturally in  nogc or -betterC.

```D
foo([1, 2, 3]) // Error: Array literal may cause GC allocation.
```

Instead you have to do this:

```D
int[3] bar = [1, 2, 3];
foo(bar); // Now it works with  nogc and -betterC
```

This obviously isn't a huge deal but it introduces a bit of 
friction into the  nogc workflow. It also makes slower, 
allocating code easier to write by default in non  nogc code.

This decision to make array literals slice types by default seems 
like a bad idea in all respects. It should be changed, array 
literals (are) should be fixed size.

But I'm still new to D, so maybe there is something that I'm 
missing. Any thoughts?
May 01
next sibling parent reply Adam D. Ruppe <destructionator gmail.com> writes:
On Saturday, 1 May 2021 at 11:32:47 UTC, Blatnik wrote:
 It also means that functions that take a slice parameter:
 Can't be called naturally in  nogc or -betterC.
There's several other options you can consider, including making foo take a static array, in which case this syntax just works, or an array variadic: foo(int[] a...) when you can call it like this: foo(1, 2, 3) or you can use the library `.staticArray` thing to expressly indicate your intention on the original foo foo([1,2,3].staticArray);
 This obviously isn't a huge deal but it introduces a bit of 
 friction into the  nogc workflow. It also makes slower, 
 allocating code easier to write by default in non  nogc code.
It also makes you less likely to accidentally write use-after-free code that refers to an array on the stack after the function returns... There's some new features that are supposed to help catch this even with static arrays (the -dip1000 switch) but that's not terribly widespread.
 But I'm still new to D, so maybe there is something that I'm 
 missing. Any thoughts?
Well, a lot of this is just history: D didn't have static arrays like it does now for a while, but a good part of it too is to make the default thing be less likely to cause crash problems by accidentally escaping a reference to the stack.
May 01
next sibling parent reply evilrat <evilrat666 gmail.com> writes:
On Saturday, 1 May 2021 at 11:50:27 UTC, Adam D. Ruppe wrote:
 or you can use the library `.staticArray` thing to expressly 
 indicate your intention on the original foo

 foo([1,2,3].staticArray);
Is there one in Phobos? Anyway this works, but maybe it can be made more type safe with constraints or just with improved symtax. ```d // compiles with -vgc and -betterC (weird, also without import stdc.core.stdio) import std.range : ElementType; template staticArray(alias T) { enum ElementType!(typeof(T))[T.length] staticArray = T; } extern(C) void main() { import core.stdc.stdio; auto arr = staticArray!([1,2,3]); pragma(msg, typeof(arr)); // int[3] foreach(i; arr) printf("%d\n", i); } ```
May 01
next sibling parent reply Adam D. Ruppe <destructionator gmail.com> writes:
On Saturday, 1 May 2021 at 12:22:50 UTC, evilrat wrote:
 Is there one in Phobos?
http://dpldocs.info/staticArray i haven't tested with -betterC restrictions but i don't see any reason why it wouldn't work there
May 01
next sibling parent Blatnik <blatblatnik gmail.com> writes:
On Saturday, 1 May 2021 at 12:27:07 UTC, Adam D. Ruppe wrote:
 i haven't tested with -betterC restrictions but i don't see any 
 reason why it wouldn't work there
Yep, `[1,2,3].staticArray` works just fine with -betterC.
May 01
prev sibling parent evilrat <evilrat666 gmail.com> writes:
On Saturday, 1 May 2021 at 12:27:07 UTC, Adam D. Ruppe wrote:
 On Saturday, 1 May 2021 at 12:22:50 UTC, evilrat wrote:
 Is there one in Phobos?
http://dpldocs.info/staticArray i haven't tested with -betterC restrictions but i don't see any reason why it wouldn't work there
Wow, I see. It uses templates to deduce type and length as parameters.
May 01
prev sibling parent reply russhy <russhy gmail.com> writes:
On Saturday, 1 May 2021 at 12:22:50 UTC, evilrat wrote:
 On Saturday, 1 May 2021 at 11:50:27 UTC, Adam D. Ruppe wrote:
 or you can use the library `.staticArray` thing to expressly 
 indicate your intention on the original foo

 foo([1,2,3].staticArray);
Is there one in Phobos? Anyway this works, but maybe it can be made more type safe with constraints or just with improved symtax. ```d // compiles with -vgc and -betterC (weird, also without import stdc.core.stdio) import std.range : ElementType; template staticArray(alias T) { enum ElementType!(typeof(T))[T.length] staticArray = T; } extern(C) void main() { import core.stdc.stdio; auto arr = staticArray!([1,2,3]); pragma(msg, typeof(arr)); // int[3] foreach(i; arr) printf("%d\n", i); } ```
don't you realize something is weird? someone is asking to be able to do auto a = [1, 2, 3] and you propose a template? this is asking people to look for alternative language auto a = new[1,2,3] <== this should be allocated array auto a = [1,2,3] <== this should be static array let's fix that, shall we? instead of telling people to bloat their files with templates
May 01
next sibling parent reply evilrat <evilrat666 gmail.com> writes:
On Saturday, 1 May 2021 at 19:49:51 UTC, russhy wrote:
 On Saturday, 1 May 2021 at 12:22:50 UTC, evilrat wrote:
 On Saturday, 1 May 2021 at 11:50:27 UTC, Adam D. Ruppe wrote:
 or you can use the library `.staticArray` thing to expressly 
 indicate your intention on the original foo

 foo([1,2,3].staticArray);
Is there one in Phobos? Anyway this works, but maybe it can be made more type safe with constraints or just with improved symtax. ```d // compiles with -vgc and -betterC (weird, also without import stdc.core.stdio) import std.range : ElementType; template staticArray(alias T) { enum ElementType!(typeof(T))[T.length] staticArray = T; } extern(C) void main() { import core.stdc.stdio; auto arr = staticArray!([1,2,3]); pragma(msg, typeof(arr)); // int[3] foreach(i; arr) printf("%d\n", i); } ```
don't you realize something is weird? someone is asking to be able to do auto a = [1, 2, 3] and you propose a template? this is asking people to look for alternative language auto a = new[1,2,3] <== this should be allocated array auto a = [1,2,3] <== this should be static array let's fix that, shall we? instead of telling people to bloat their files with templates
You see only what you wanted to see. Let me clarify something. That code proves that unlike it was stated "array type information is gone" it actually isn't, which this code proves. It provides workaround just is case. I'm not forcing anyone to use it, and there is simpler solution (still a template one) in phobos. And finally, I haven't said anything like "D DONT NEED THIS, STFU AND USE HACKS". But after recent discussion you seem to trigger just by seeing my posts. No thanks I don't need any stalkers following me around.
May 01
parent russhy <russhy gmail.com> writes:
On Sunday, 2 May 2021 at 05:57:02 UTC, evilrat wrote:
 On Saturday, 1 May 2021 at 19:49:51 UTC, russhy wrote:
 On Saturday, 1 May 2021 at 12:22:50 UTC, evilrat wrote:
 On Saturday, 1 May 2021 at 11:50:27 UTC, Adam D. Ruppe wrote:
 or you can use the library `.staticArray` thing to expressly 
 indicate your intention on the original foo

 foo([1,2,3].staticArray);
Is there one in Phobos? Anyway this works, but maybe it can be made more type safe with constraints or just with improved symtax. ```d // compiles with -vgc and -betterC (weird, also without import stdc.core.stdio) import std.range : ElementType; template staticArray(alias T) { enum ElementType!(typeof(T))[T.length] staticArray = T; } extern(C) void main() { import core.stdc.stdio; auto arr = staticArray!([1,2,3]); pragma(msg, typeof(arr)); // int[3] foreach(i; arr) printf("%d\n", i); } ```
don't you realize something is weird? someone is asking to be able to do auto a = [1, 2, 3] and you propose a template? this is asking people to look for alternative language auto a = new[1,2,3] <== this should be allocated array auto a = [1,2,3] <== this should be static array let's fix that, shall we? instead of telling people to bloat their files with templates
You see only what you wanted to see. Let me clarify something. That code proves that unlike it was stated "array type information is gone" it actually isn't, which this code proves. It provides workaround just is case. I'm not forcing anyone to use it, and there is simpler solution (still a template one) in phobos. And finally, I haven't said anything like "D DONT NEED THIS, STFU AND USE HACKS". But after recent discussion you seem to trigger just by seeing my posts. No thanks I don't need any stalkers following me around.
i'm not stalking you, i don't even read the user name when i reply to messages, i focus on their content today is you, yesterday it was another person, tomorow will probably be another person, that's the way it is, i find things that annoys me, i reply nobody else seems to be "triggered" by the need of such "workaround", i decided it would be me
May 02
prev sibling next sibling parent reply Imperatorn <johan_forsberg_86 hotmail.com> writes:
On Saturday, 1 May 2021 at 19:49:51 UTC, russhy wrote:
 On Saturday, 1 May 2021 at 12:22:50 UTC, evilrat wrote:
 On Saturday, 1 May 2021 at 11:50:27 UTC, Adam D. Ruppe wrote:
[...]
Is there one in Phobos? Anyway this works, but maybe it can be made more type safe with constraints or just with improved symtax. ```d // compiles with -vgc and -betterC (weird, also without import stdc.core.stdio) import std.range : ElementType; template staticArray(alias T) { enum ElementType!(typeof(T))[T.length] staticArray = T; } extern(C) void main() { import core.stdc.stdio; auto arr = staticArray!([1,2,3]); pragma(msg, typeof(arr)); // int[3] foreach(i; arr) printf("%d\n", i); } ```
don't you realize something is weird? someone is asking to be able to do auto a = [1, 2, 3] and you propose a template? this is asking people to look for alternative language auto a = new[1,2,3] <== this should be allocated array auto a = [1,2,3] <== this should be static array let's fix that, shall we? instead of telling people to bloat their files with templates
Is there any way to enable this in the language? ```d auto a = [1,2,3] + [4,5,6]; //[5,7,9] ``` I want to allow the operation. If I made a dmd fork, could I change this behavior "easily" or would it require a blood sacrifice
May 02
parent reply Q. Schroll <qs.il.paperinik gmail.com> writes:
On Sunday, 2 May 2021 at 08:05:49 UTC, Imperatorn wrote:
 Is there any way to enable this in the language?

 ```d
 auto a = [1,2,3] + [4,5,6]; //[5,7,9]
 ```

 I want to allow the operation.

 If I made a dmd fork, could I change this behavior "easily" or 
 would it require a blood sacrifice
You could enable this easily using a wrapping struct template. Have a look at this: https://run.dlang.io/is/6CNgpy In short, the solution is very elegant, very general, and only requires you to make two keystrokes `.v` before the operation. Alternatively, you can use `v(1, 2, 3)` instead of a slice literal.
May 03
parent reply Imperatorn <johan_forsberg_86 hotmail.com> writes:
On Tuesday, 4 May 2021 at 00:34:49 UTC, Q. Schroll wrote:
 On Sunday, 2 May 2021 at 08:05:49 UTC, Imperatorn wrote:
 Is there any way to enable this in the language?

 ```d
 auto a = [1,2,3] + [4,5,6]; //[5,7,9]
 ```

 I want to allow the operation.

 If I made a dmd fork, could I change this behavior "easily" or 
 would it require a blood sacrifice
You could enable this easily using a wrapping struct template. Have a look at this: https://run.dlang.io/is/6CNgpy In short, the solution is very elegant, very general, and only requires you to make two keystrokes `.v` before the operation. Alternatively, you can use `v(1, 2, 3)` instead of a slice literal.
Interesting! Even more cool if not the .v was required tho 😁
May 03
parent reply Q. Schroll <qs.il.paperinik gmail.com> writes:
On Tuesday, 4 May 2021 at 05:24:11 UTC, Imperatorn wrote:
 On Tuesday, 4 May 2021 at 00:34:49 UTC, Q. Schroll wrote:
 On Sunday, 2 May 2021 at 08:05:49 UTC, Imperatorn wrote:
 Is there any way to enable this in the language?

 ```d
 auto a = [1,2,3] + [4,5,6]; //[5,7,9]
 ```

 I want to allow the operation.

 If I made a dmd fork, could I change this behavior "easily" 
 or would it require a blood sacrifice
You could enable this easily using a wrapping struct template. Have a look at this: https://run.dlang.io/is/6CNgpy In short, the solution is very elegant, very general, and only requires you to make two keystrokes `.v` before the operation. Alternatively, you can use `v(1, 2, 3)` instead of a slice literal.
Interesting! Even more cool if not the .v was required tho 😁
The operation necessitates an allocation and people here don't like hidden allocations.
May 04
next sibling parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Tue, May 04, 2021 at 06:16:15PM +0000, Q. Schroll via Digitalmars-d wrote:
 On Tuesday, 4 May 2021 at 05:24:11 UTC, Imperatorn wrote:
 On Tuesday, 4 May 2021 at 00:34:49 UTC, Q. Schroll wrote:
 On Sunday, 2 May 2021 at 08:05:49 UTC, Imperatorn wrote:
 Is there any way to enable this in the language?
 
 ```d
 auto a = [1,2,3] + [4,5,6]; //[5,7,9]
 ```
[...]
 Alternatively, you can use `v(1, 2, 3)` instead of a slice literal.
Interesting! Even more cool if not the .v was required tho 😁
The operation necessitates an allocation and people here don't like hidden allocations.
Why would an allocation be necessary? struct Vec(E, size_t n) { E[n] impl; alias impl this; E[n] opBinary(string op)(Vec v) { Vec result; mixin("result.impl[] = impl[] "~op~" v.impl[];"); return result; } } auto v(Args...)(Args args) { import std.traits : CommonType; alias E = CommonType!Args; Vec!(E, Args.length) result; result.impl = [ args ]; return result; } void main() nogc { // Look, ma! No allocations! int[3] arr = v(1,2,3) + v(4,5,6); assert(arr[0] == 5 && arr[1] == 7 && arr[2] == 9); } T -- Some ideas are so stupid that only intellectuals could believe them. -- George Orwell
May 04
parent reply Imperatorn <johan_forsberg_86 hotmail.com> writes:
On Tuesday, 4 May 2021 at 18:53:18 UTC, H. S. Teoh wrote:
 On Tue, May 04, 2021 at 06:16:15PM +0000, Q. Schroll via 
 Digitalmars-d wrote:
 On Tuesday, 4 May 2021 at 05:24:11 UTC, Imperatorn wrote:
 On Tuesday, 4 May 2021 at 00:34:49 UTC, Q. Schroll wrote:
 On Sunday, 2 May 2021 at 08:05:49 UTC, Imperatorn wrote:
 Is there any way to enable this in the language?
 
 ```d
 auto a = [1,2,3] + [4,5,6]; //[5,7,9]
 ```
[...]
 Alternatively, you can use `v(1, 2, 3)` instead of a slice 
 literal.
Interesting! Even more cool if not the .v was required tho 😁
The operation necessitates an allocation and people here don't like hidden allocations.
Why would an allocation be necessary? struct Vec(E, size_t n) { E[n] impl; alias impl this; E[n] opBinary(string op)(Vec v) { Vec result; mixin("result.impl[] = impl[] "~op~" v.impl[];"); return result; } } auto v(Args...)(Args args) { import std.traits : CommonType; alias E = CommonType!Args; Vec!(E, Args.length) result; result.impl = [ args ]; return result; } void main() nogc { // Look, ma! No allocations! int[3] arr = v(1,2,3) + v(4,5,6); assert(arr[0] == 5 && arr[1] == 7 && arr[2] == 9); } T -- Some ideas are so stupid that only intellectuals could believe them. -- George Orwell
To the high priests of D (I have only written *one* project in D so far): What would it take to allow array operations like I said before, without rewriting: ```d auto a = [1,2,3] + [3,2,1]; //[4,4,4] ``` Can this be accomplished using templates or a library solution, or do I have to modify the compiler? Thanks
May 04
next sibling parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Tuesday, 4 May 2021 at 19:44:24 UTC, Imperatorn wrote:
 What would it take to allow array operations like I said 
 before, without rewriting:

 ```d
 auto a = [1,2,3] + [3,2,1]; //[4,4,4]
 ```

 Can this be accomplished using templates or a library solution, 
 or do I have to modify the compiler?
C++ allows operator overloading for free-standing operator functions, D does not. Adding this to the compiler is easy enough. You just rewrite all "+" operators to some internal __add(x,y) template and then default that back to "+", then overload it for anything you want... Clunky, but it should work?
May 04
parent Imperatorn <johan_forsberg_86 hotmail.com> writes:
On Tuesday, 4 May 2021 at 20:16:29 UTC, Ola Fosheim GrΓΈstad wrote:
 On Tuesday, 4 May 2021 at 19:44:24 UTC, Imperatorn wrote:
 What would it take to allow array operations like I said 
 before, without rewriting:

 ```d
 auto a = [1,2,3] + [3,2,1]; //[4,4,4]
 ```

 Can this be accomplished using templates or a library 
 solution, or do I have to modify the compiler?
C++ allows operator overloading for free-standing operator functions, D does not. Adding this to the compiler is easy enough. You just rewrite all "+" operators to some internal __add(x,y) template and then default that back to "+", then overload it for anything you want... Clunky, but it should work?
Thanks everyone for all clarifications and examples! I'll experiment a bit and see what makes most sense.
May 04
prev sibling next sibling parent Q. Schroll <qs.il.paperinik gmail.com> writes:
On Tuesday, 4 May 2021 at 19:44:24 UTC, Imperatorn wrote:
 On Tuesday, 4 May 2021 at 18:53:18 UTC, H. S. Teoh wrote:
 On Tue, May 04, 2021 at 06:16:15PM +0000, Q. Schroll via 
 Digitalmars-d wrote:
 On Tuesday, 4 May 2021 at 05:24:11 UTC, Imperatorn wrote:
 On Tuesday, 4 May 2021 at 00:34:49 UTC, Q. Schroll wrote:
 On Sunday, 2 May 2021 at 08:05:49 UTC, Imperatorn wrote:
 Is there any way to enable this in the language?
 
 ```d
 auto a = [1,2,3] + [4,5,6]; //[5,7,9]
 ```
[...]
 Alternatively, you can use `v(1, 2, 3)` instead of a 
 slice literal.
Interesting! Even more cool if not the .v was required tho 😁
The operation necessitates an allocation and people here don't like hidden allocations.
Why would an allocation be necessary? struct Vec(E, size_t n) { E[n] impl; alias impl this; E[n] opBinary(string op)(Vec v) { Vec result; mixin("result.impl[] = impl[] "~op~" v.impl[];"); return result; } } auto v(Args...)(Args args) { import std.traits : CommonType; alias E = CommonType!Args; Vec!(E, Args.length) result; result.impl = [ args ]; return result; } void main() nogc { // Look, ma! No allocations! int[3] arr = v(1,2,3) + v(4,5,6); assert(arr[0] == 5 && arr[1] == 7 && arr[2] == 9); }
To the high priests of D (I have only written *one* project in D so far): What would it take to allow array operations like I said before, without rewriting: ```d auto a = [1,2,3] + [3,2,1]; //[4,4,4] ``` Can this be accomplished using templates or a library solution, or do I have to modify the compiler?
Array literals are internal to the compiler. But you can just use something different like v(1,2,3). Heck, you can get even closer using a struct with static `opIndex` to resemble the look-and-feel of array literals: `v[1,2,3]`. You can adapt H. S. Teoh's or my approach. This is how it's done: ```D // for the array-literal-like syntax struct v { import std.traits : CommonType; static Vec!(CommonType!Args, Args.length) opIndex(Args...)(Args args) { return typeof(return)([args]); } } // the type of objects you create: struct Vector(...) { ... } // by H. S. Teoh void main() nogc { // Look, ma! No allocations! int[3] arr = v[1,2,3] + v[4,5,6]; assert(arr[0] == 5 && arr[1] == 7 && arr[2] == 9); } ```
May 04
prev sibling parent reply Blatnik <blatblatnik gmail.com> writes:
On Tuesday, 4 May 2021 at 19:44:24 UTC, Imperatorn wrote:
 ```d
 auto a = [1,2,3] + [3,2,1]; //[4,4,4]
 ```

 Can this be accomplished using templates or a library solution, 
 or do I have to modify the compiler?
I'm by no means a high priest of D. However I'm fairly confident the answer to your question is no. ```D // Built-in: int[3] a = [1,2,3] + [3,2,1]; // You can do this. auto a = [1,2,3] + [3,2,1]; // But not this. // With H.S. Teoh's thing: auto a = v(1,2,3) + v(3,2,1); // You can do this - a is int[3]. auto a = v(1,2,3) + v(3,2,1) + v(42,42,42); // But not this - Error: Invalid array operation. ``` So if you actually want to make this universal, you would need to modify the compiler. From my own testing, the compiler actually turns these kinds of expressions into a function call. ```D int[3] a = [1,2,3] + [3,2,1]; // Gets turned into something like .. import core.internal.array.operations; int[3] a; int[3] __temp1 = [1,2,3]; int[3] __temp2 = [3,2,1]; arrayOp!(int[], int[], int[], "+", "=")(a[], __temp1[], __temp2[], "+", "="); ``` This also might explain why you can't use `auto a = ...` (it's not a great excuse).
May 04
parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Tue, May 04, 2021 at 09:49:16PM +0000, Blatnik via Digitalmars-d wrote:
[...]
 ```
 // With H.S. Teoh's thing:
 auto a = v(1,2,3) + v(3,2,1); // You can do this - a is int[3].
 auto a = v(1,2,3) + v(3,2,1) + v(42,42,42); // But not this - Error: Invalid
 array operation.
 ```
[...] The only reason it's invalid is because I made opBinary return E[n] rather than Vec!(E,n). If it returned Vec instead, then arbitrary expressions can be made possible (e.g., with generic overloads for opBinary and opUnary). With alias this, the Vec struct will become a thin wrapper over static arrays; `auto` will give you Vec!(E,n) rather than E[n], but any use of it that needs E[n] will automatically decay to E[n]. It's not 100% the same as built-in static array expressions, but it's pretty darned close. T -- He who does not appreciate the beauty of language is not worthy to bemoan its flaws.
May 04
prev sibling parent Timon Gehr <timon.gehr gmx.ch> writes:
On 04.05.21 20:16, Q. Schroll wrote:
 
 The operation necessitates an allocation and people here don't like 
 hidden allocations.
(Just some of them. Some of them obnoxiously loud. They shouldn't dictate language evolution.)
May 05
prev sibling next sibling parent reply Imperatorn <johan_forsberg_86 hotmail.com> writes:
On Saturday, 1 May 2021 at 19:49:51 UTC, russhy wrote:
 On Saturday, 1 May 2021 at 12:22:50 UTC, evilrat wrote:
 On Saturday, 1 May 2021 at 11:50:27 UTC, Adam D. Ruppe wrote:
[...]
Is there one in Phobos? Anyway this works, but maybe it can be made more type safe with constraints or just with improved symtax. ```d // compiles with -vgc and -betterC (weird, also without import stdc.core.stdio) import std.range : ElementType; template staticArray(alias T) { enum ElementType!(typeof(T))[T.length] staticArray = T; } extern(C) void main() { import core.stdc.stdio; auto arr = staticArray!([1,2,3]); pragma(msg, typeof(arr)); // int[3] foreach(i; arr) printf("%d\n", i); } ```
don't you realize something is weird? someone is asking to be able to do auto a = [1, 2, 3] and you propose a template? this is asking people to look for alternative language auto a = new[1,2,3] <== this should be allocated array auto a = [1,2,3] <== this should be static array let's fix that, shall we? instead of telling people to bloat their files with templates
Is there any way to enable this in the language? ```d auto a = [1,2,3] + [4,5,6]; //[5,7,9] ``` I want to allow the operation. If I made a dmd fork, could I change this behavior "easily" or would it require a blood sacrifice
May 02
parent reply norm <norm.rowtree gmail.com> writes:
On Sunday, 2 May 2021 at 08:07:58 UTC, Imperatorn wrote:
 On Saturday, 1 May 2021 at 19:49:51 UTC, russhy wrote:
 On Saturday, 1 May 2021 at 12:22:50 UTC, evilrat wrote:
 On Saturday, 1 May 2021 at 11:50:27 UTC, Adam D. Ruppe wrote:
[...]
Is there one in Phobos? Anyway this works, but maybe it can be made more type safe with constraints or just with improved symtax. ```d // compiles with -vgc and -betterC (weird, also without import stdc.core.stdio) import std.range : ElementType; template staticArray(alias T) { enum ElementType!(typeof(T))[T.length] staticArray = T; } extern(C) void main() { import core.stdc.stdio; auto arr = staticArray!([1,2,3]); pragma(msg, typeof(arr)); // int[3] foreach(i; arr) printf("%d\n", i); } ```
don't you realize something is weird? someone is asking to be able to do auto a = [1, 2, 3] and you propose a template? this is asking people to look for alternative language auto a = new[1,2,3] <== this should be allocated array auto a = [1,2,3] <== this should be static array let's fix that, shall we? instead of telling people to bloat their files with templates
Is there any way to enable this in the language? ```d auto a = [1,2,3] + [4,5,6]; //[5,7,9] ``` I want to allow the operation. If I made a dmd fork, could I change this behavior "easily" or would it require a blood sacrifice
I think there was once a PR that made this nice and easy: https://github.com/dlang/dmd/pull/3615 ```d auto a[$] = [1,2,3]; ``` I was disappointed it never got accepted but I am sure there were good reasons. At the time I think it was "this should be a library solution" and that was probably where `staticArray` came from
May 03
next sibling parent norm <norm.rowtree gmail.com> writes:
On Tuesday, 4 May 2021 at 01:59:48 UTC, norm wrote:
 ```d
 auto a[$] = [1,2,3];
 ```
gah! too much C not enough D lately; `auto[$] a = [1,2,3];`
May 03
prev sibling parent reply Blatnik <blatblatnik gmail.com> writes:
On Tuesday, 4 May 2021 at 01:59:48 UTC, norm wrote:
 https://github.com/dlang/dmd/pull/3615

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

 I was disappointed it never got accepted but I am sure there 
 were good reasons. At the time I think it was "this should be a 
 library solution" and that was probably where `staticArray` 
 came from
Oh that is pretty disappointing... I actually intuitively tried to do this while I was learning D. So IMO it fits the language perfectly. It looks like it wasn't merged because Andrei and Walter thought it complicates the language needlessly (https://github.com/dlang/dmd/pull/3615#issuecomment-72397283). There's still this DIP: https://github.com/dlang/DIPs/blob/master/DIPs/DIP1039.md & https://forum.dlang.org/thread/ucqyqkvaznbxkasvdjpx forum.dlang.org?page=3.
May 04
next sibling parent Mike Parker <aldacron gmail.com> writes:
On Tuesday, 4 May 2021 at 10:09:59 UTC, Blatnik wrote:

 There's still this DIP: 
 https://github.com/dlang/DIPs/blob/master/DIPs/DIP1039.md & 
 https://forum.dlang.org/thread/ucqyqkvaznbxkasvdjpx forum.dlang.org?page=3.
The DIP author asked me to put this on hold until he can complete an implementation. His schedule prohibits that happening for a while yet. My current expectation is that we'll be ready to move forward with it by September.
May 04
prev sibling parent Imperatorn <johan_forsberg_86 hotmail.com> writes:
On Tuesday, 4 May 2021 at 10:09:59 UTC, Blatnik wrote:
 On Tuesday, 4 May 2021 at 01:59:48 UTC, norm wrote:
 [...]
Oh that is pretty disappointing... I actually intuitively tried to do this while I was learning D. So IMO it fits the language perfectly. It looks like it wasn't merged because Andrei and Walter thought it complicates the language needlessly (https://github.com/dlang/dmd/pull/3615#issuecomment-72397283). There's still this DIP: https://github.com/dlang/DIPs/blob/master/DIPs/DIP1039.md & https://forum.dlang.org/thread/ucqyqkvaznbxkasvdjpx forum.dlang.org?page=3.
Would be nice if that DIP got some love. But, that would *still* not enable stuff like ```d auto a = [1,2,3] + [3,2,1]; //[4,4,4] ``` right?
May 04
prev sibling parent Q. Schroll <qs.il.paperinik gmail.com> writes:
On Saturday, 1 May 2021 at 19:49:51 UTC, russhy wrote:
 On Saturday, 1 May 2021 at 12:22:50 UTC, evilrat wrote:
 On Saturday, 1 May 2021 at 11:50:27 UTC, Adam D. Ruppe wrote:
 or you can use the library `.staticArray` thing to expressly 
 indicate your intention on the original foo

 foo([1,2,3].staticArray);
Is there one in Phobos? Anyway this works, but maybe it can be made more type safe with constraints or just with improved symtax. ```d // compiles with -vgc and -betterC (weird, also without import stdc.core.stdio) import std.range : ElementType; template staticArray(alias T) { enum ElementType!(typeof(T))[T.length] staticArray = T; } extern(C) void main() { import core.stdc.stdio; auto arr = staticArray!([1,2,3]); pragma(msg, typeof(arr)); // int[3] foreach(i; arr) printf("%d\n", i); } ```
don't you realize something is weird? someone is asking to be able to do auto a = [1, 2, 3] and you propose a template? this is asking people to look for alternative language ```D auto a = new[1,2,3] <== this should be allocated array auto a = [1,2,3] <== this should be static array ``` let's fix that, shall we? instead of telling people to bloat their files with templates
I agree that the non-obvious allocation is kind of a problem and `new [ 1, 2, 3 ]` would be more explicit, but where I see the actual issue isn't where you think it is. In ` nogc` code, the compiler tells you that an allocation takes place and you look for solutions to avoid it (there are multiple approaches, but no general one).
May 03
prev sibling parent reply Blatnik <blatblatnik gmail.com> writes:
On Saturday, 1 May 2021 at 11:50:27 UTC, Adam D. Ruppe wrote:
 There's several other options you can consider, including 
 making foo take a static array
Yea this does work, but some functions really do need to take many different array sizes. And in that case I guess you could make the array size a template parameter. But this would lead to template bloat for no reason in most cases.
 or an array variadic:

 foo(int[] a...)
This doesn't really work. It has the obvious problem of not being able to pass 2 different arrays like this.
 or you can use the library `.staticArray` thing to expressly 
 indicate your intention on the original foo
But this does work! I didn't know `std.array` had this. Thanks.
 but a good part of it too is to make the default thing be less 
 likely to cause crash problems by accidentally escaping a 
 reference to the stack.
You mean stuff like: ```D int[] bug() { return [1, 2, 3]; } int[] a = bug(); a[0] = 42; // Works fine now, but use-after-free-ish if array literals are static arrays. ``` Yea I can see how that would be a problem if array literals were static arrays by default. But even right now the compiler is able to catch this mistake pretty easily: ```D int[] bug() { int[3] a = [1, 2, 3]; return a; // Error: Returning `a` escapes a reference to a local variable. } ``` So the `.staticArray` thing is great but wouldn't it be even better if we didn't have to import a library and type that in. I still see no reason `[1, 2, 3]` should ever _not_ be considered a `int[3]`, unless you explicitly ask for it: ```D auto x = [1, 2, 3]; // This really shouldn't allocate anything. auto y = [1, 2, 3].dup; // I explicitly asked for it, please allocate! ```
May 01
next sibling parent reply Adam D. Ruppe <destructionator gmail.com> writes:
On Saturday, 1 May 2021 at 12:27:30 UTC, Blatnik wrote:
 Yea I can see how that would be a problem if array literals 
 were static arrays by default. But even right now the compiler 
 is able to catch this mistake pretty easily:
Yeah, it works now but that's again relatively new. It wasn't there when this stuff was designed. It'd probably break a lot of code if this were to change now.
 auto y = [1, 2, 3].dup; // I explicitly asked for it, please 
 allocate!
yeah that'd probably be ok.
May 01
next sibling parent Blatnik <blatblatnik gmail.com> writes:
On Saturday, 1 May 2021 at 12:35:00 UTC, Adam D. Ruppe wrote:
 It'd probably break a lot of code if this were to change now.
But the compiler could probably catch the mistake everywhere it happens with DIP 1000. And then it's just a matter of replacing [...] with [...].dup where you actually need it. Although to be fair, even though the compiler (dmd) catches really simple cases, it doesn't catch more complex ones: ```D int[] bug1() { int[3] a = [1, 2, 3]; return a; // Error: Returning `a` escapes reference to a local variable. } int[] bug2() { int[3] a = [1, 2, 3]; int[] b = a; return b; // No error! } ``` But with DIP 1000 this is caught as well: ```D int[] bug2() { int[3] a = [1, 2, 3]; int[] b = a; return b; // Error: Scope variable `b` may not be returned. } ```
May 01
prev sibling parent Blatnik <blatblatnik gmail.com> writes:
On Saturday, 1 May 2021 at 12:35:00 UTC, Adam D. Ruppe wrote:
 Yeah, it works now but that's again relatively new. It wasn't 
 there when this stuff was designed.

 It'd probably break a lot of code if this were to change now.
I guess the conclusion is, D's array literals are weird for historic reasons. There are definitely more important things that need fixing. This would be a breaking change with relatively not that much benefit. The `.staticArray` thing is good enough for me. Still there is some performance / language simplification to be gained here.
May 01
prev sibling parent reply Mike Parker <aldacron gmail.com> writes:
On Saturday, 1 May 2021 at 12:27:30 UTC, Blatnik wrote:

 I still see no reason `[1, 2, 3]` should ever _not_ be 
 considered a `int[3]`, unless you explicitly ask for it:
I strongly disagree. That array literals produce dynamic arrays made sense to me from the day I found D, and it still makes sense 18 years later. If they were to produce static arrays, then what happens here? ```d int[] a = [1, 2, 3]; return a; ``` In order for this to work as expected, then this particular literal would have to be allocated on the GC heap, which is then inconsistent with the normal behavior. Right now, the compiler is free to elide allocations for literals when it can, but that's not an optimization, not an inconsistency. And what about this? ```d doSomeMatrixStuff3x3( [1.0, 0.0, 0.0, 0.0, 1.0, 0.0, 0.0, 0.0, 1.0] ); ``` Now I'm passing 9 floats by value unless I remember to do whatever needs to be done to indicate that this should be dynamic (`.dup`). Static array literals just seem backwards to me. With dynamic array literals, I don't have to think about it. Moreover, I really would hate to see either ` nogc` or BetterC have any impact on language changes. Those are the *exceptional* cases. D is a GC'ed language. ` nogc` and BetterC are more restricted subsets.
May 01
next sibling parent Mike Parker <aldacron gmail.com> writes:
On Saturday, 1 May 2021 at 15:14:49 UTC, Mike Parker wrote:


 but that's not an optimization, not an inconsistency.
but that's an optimization...
May 01
prev sibling parent reply Blatnik <blatblatnik gmail.com> writes:
On Saturday, 1 May 2021 at 15:14:49 UTC, Mike Parker wrote:
 I strongly disagree. That array literals produce dynamic arrays 
 made sense to me from the day I found D, and it still makes 
 sense 18 years later.
I really can't argue here. If you just want to not think about it, then having it always be dynamically allocated is the way to go. But isn't D a systems level programming language where you _do_ want to care about things like what is dynamically allocated and what isn't? :D If so then the language should encourage you to allocate statically wherever possible. At least in my view.
 If they were to produce static arrays, then what happens here?

 ```d
 int[] a = [1, 2, 3];
 return a;
 ```
Well the way I saw my idea working is that the compiler would give you a hard error here, and tell you to fix it by allocating it with `return a.dup` if that's what you wanted, or make the function return a static array if _that's_ what you wanted.
 And what about this?

 ```d
 doSomeMatrixStuff3x3(
     [1.0, 0.0, 0.0,
      0.0, 1.0, 0.0,
      0.0, 0.0, 1.0]
 );
 ```

 Now I'm passing 9 floats by value unless I remember to do 
 whatever needs to be done to indicate that this should be 
 dynamic (`.dup`).
Unless `doSomeMatrixStuff3x3` does something stupid like copying the slice to a global variable, then you don't need to dynamically allocate the temporary before you pass it in anyway. So if the array literals were static, the compiler would turn the call above into something like: ```D float[9] __temporary = [1, 0, 0, 0, 1, 0, 0, 0, 1]; doSomeMatrixStuff3x3(__temporary[]); ``` This is what you end up doing in -betterC and nogc anyway, and without them this will still save you an unnecessary allocation. Note that if `doSomeMatrixStuff3x3` _does_ save the slice to a global variable or something, that's already incorrect today, as you could in theory pass in a stack allocated static array as a slice (exactly like it is being called above).
 Moreover, I really would hate to see either ` nogc` or BetterC 
 have any impact on language changes. Those are the 
 *exceptional* cases. D is a GC'ed language. ` nogc` and BetterC 
 are more restricted subsets.
I see your point. This change would make code without nogc slightly more annoying to write because of the error messages when you try to do something like the above, which is fine to do right now. But I guess in my view this could be a (slightly) helpful change for (every subset of) the language.
May 01
next sibling parent Adam D. Ruppe <destructionator gmail.com> writes:
On Saturday, 1 May 2021 at 18:57:48 UTC, Blatnik wrote:
 But isn't D a systems level programming language where you _do_ 
 want to care about things like what is dynamically allocated 
 and what isn't? :D
D is an all-purpose programming language. Some purposes are easier or harder than others. The easier thing tries to be more correct than not, even if that means extra performance may take extra work.
May 01
prev sibling parent MoonlightSentinel <moonlightsentinel disroot.org> writes:
On Saturday, 1 May 2021 at 18:57:48 UTC, Blatnik wrote:
 ```D
 float[9] __temporary = [1, 0, 0, 0, 1, 0, 0, 0, 1];
 doSomeMatrixStuff3x3(__temporary[]);
 ```

 This is what you end up doing in -betterC and  nogc anyway, and 
 without them this will still save you an unnecessary allocation.
The stack propagation is unrelated to -betterC, it only depends on the parameter being marked as scope.
May 01
prev sibling next sibling parent Imperatorn <johan_forsberg_86 hotmail.com> writes:
On Saturday, 1 May 2021 at 11:32:47 UTC, Blatnik wrote:
 I love how D redesigned the terrible C/C++ arrays. And it's 
 awesome that array operations like element wise +, -, etc. are 
 built into the language - it makes me want to use arrays and 
 slices for everything. But there are still some rough edges in 
 the design.

 [...]
Yeah, imo this is a rather strange limitation of the language. I would like to be able to do ```d int[] a = [1,2,3] * [4,5,6]; ``` for example, but this yields "array operation without destination memory not allowed" :(
May 01
prev sibling next sibling parent Dennis <dkorpel gmail.com> writes:
On Saturday, 1 May 2021 at 11:32:47 UTC, Blatnik wrote:
 Why? What's the reason for this design?
As mentioned before, static arrays have limited life time, so the compiler allocates arrays using the GC unless it is certain no references to it could escape.
 It also means that functions that take a slice parameter:

 ```D
 void foo(int[] bar);
 ```

 Can't be called naturally in  nogc or -betterC.

 ```D
 foo([1, 2, 3]) // Error: Array literal may cause GC allocation.
 ```
In this case, `foo` could e.g. store `bar` in a global variable causing memory corruption. It does work in `-betterC` if you add `scope` to the parameter, which means that `bar` is not allowed to leave the scope of the function: ```D void foo(scope int[] bar) nogc {} extern(C) void main() nogc { foo([1, 2, 3]); } ```
 This decision to make array literals slice types by default 
 seems like a bad idea in all respects. It should be changed, 
 array literals (are) should be fixed size.
It would have to be done in a backwards compatible way, array literals are too common to introduce a breaking change.
 Any thoughts?
D's literals are full of somewhat ad-hoc rules that allow / disallow certain assignments that don't follow from their types. - a string literal converts to a C-style string `const(char)*`, but a `string` does not convert to a `const(char)*` - an integer literal converts to a `short` if it fits, though `int` does not convert to `short` (this is called "value range propagation") - an integer array literal `[1, 2, 3]` converts to a `float[]`, though an `int[]` does not convert to `float[]` - conversely, an invalid code point `0x110000` can *not* be assigned to a `dchar`, even though `int` converts to `dchar` The fact that static arrays are initialized using dynamic array literals is another instance of this. I'd personally be in favor of dedicated static array literals, but I'm afraid most people are satisfied with `import std.array: staticArray;`.
May 01
prev sibling parent reply user1234 <user1234 12.de> writes:
On Saturday, 1 May 2021 at 11:32:47 UTC, Blatnik wrote:
 I love how D redesigned the terrible C/C++ arrays. And it's 
 awesome that array operations like element wise +, -, etc. are 
 built into the language - it makes me want to use arrays and 
 slices for everything. But there are still some rough edges in 
 the design.

 What do you expect to happen when you run this:

 ```D
 import std;
 void main() {
   writeln(typeid([1, 2, 3]));
 }
 ```

 Maybe I'm crazy, but I would expect `int[3]` to be printed. But 
 `int[]` gets printed instead.

 Why? What's the reason for this design?

 This automatic downconversion loses potentially useful type 
 information by default. It also means lazy code like this:

 ```D
 auto array = [1, 2, 3]; // Type deduced as int[], not int[3]
 ```

 performs an allocation, and thus it can't be used in  nogc or 
 -betterC. (Not to mention that it's a completely unnecessary 
 memory allocation).

 It also means that functions that take a slice parameter:

 ```D
 void foo(int[] bar);
 ```

 Can't be called naturally in  nogc or -betterC.

 ```D
 foo([1, 2, 3]) // Error: Array literal may cause GC allocation.
 ```
related : https://issues.dlang.org/show_bug.cgi?id=21756
 Instead you have to do this:

 ...
May 05
parent reply Imperatorn <johan_forsberg_86 hotmail.com> writes:
On Wednesday, 5 May 2021 at 08:58:41 UTC, user1234 wrote:
 On Saturday, 1 May 2021 at 11:32:47 UTC, Blatnik wrote:
 I love how D redesigned the terrible C/C++ arrays. And it's 
 awesome that array operations like element wise +, -, etc. are 
 built into the language - it makes me want to use arrays and 
 slices for everything. But there are still some rough edges in 
 the design.
I have experimented some and found a few workarounds which might be acceptable. But, I'm having some weird bug. On dmd and dmd-beta it works, but on dmd-nightly I get: cannot interpret array literal expression [1, 2, 3] + [3, 2, 1] at compile time I think this might be a regression? Like, this works as I want: https://run.dlang.io/is/rHRiP9 If I use dmd or dmd-beta. But if I change it to dmd-nightly it doesn't :( 😒😒😒
May 05
next sibling parent reply user1234 <user1234 12.de> writes:
On Wednesday, 5 May 2021 at 09:18:58 UTC, Imperatorn wrote:
 If I use dmd or dmd-beta. But if I change it to dmd-nightly it 
 doesn't :(
That's because nightlies are broken. The compiler used is actually somewhere between 2.091 and 2.092 : https://run.dlang.io/is/foS0FX Also visible there : http://downloads.dlang.org/nightlies/. There are not even promoted on the main download page, as it used to be.
May 05
parent reply Imperatorn <johan_forsberg_86 hotmail.com> writes:
On Wednesday, 5 May 2021 at 09:26:39 UTC, user1234 wrote:
 On Wednesday, 5 May 2021 at 09:18:58 UTC, Imperatorn wrote:
 If I use dmd or dmd-beta. But if I change it to dmd-nightly it 
 doesn't :(
That's because nightlies are broken. The compiler used is actually somewhere between 2.091 and 2.092 : https://run.dlang.io/is/foS0FX Also visible there : http://downloads.dlang.org/nightlies/. There are not even promoted on the main download page, as it used to be.
Oh, what's happening? I thought nightly was nightly :D
May 05
parent reply user1234 <user1234 12.de> writes:
On Wednesday, 5 May 2021 at 09:42:01 UTC, Imperatorn wrote:
 On Wednesday, 5 May 2021 at 09:26:39 UTC, user1234 wrote:
 On Wednesday, 5 May 2021 at 09:18:58 UTC, Imperatorn wrote:
 If I use dmd or dmd-beta. But if I change it to dmd-nightly 
 it doesn't :(
That's because nightlies are broken. The compiler used is actually somewhere between 2.091 and 2.092 : https://run.dlang.io/is/foS0FX Also visible there : http://downloads.dlang.org/nightlies/. There are not even promoted on the main download page, as it used to be.
Oh, what's happening? I thought nightly was nightly :D
They could be restored soon. There's a related PR https://github.com/dlang/dmd/pull/12491, it's not sure if it aims at restoring nighlies. It 90% sure tho.
May 05
parent Imperatorn <johan_forsberg_86 hotmail.com> writes:
On Wednesday, 5 May 2021 at 09:47:37 UTC, user1234 wrote:
 On Wednesday, 5 May 2021 at 09:42:01 UTC, Imperatorn wrote:
 On Wednesday, 5 May 2021 at 09:26:39 UTC, user1234 wrote:
 On Wednesday, 5 May 2021 at 09:18:58 UTC, Imperatorn wrote:
 If I use dmd or dmd-beta. But if I change it to dmd-nightly 
 it doesn't :(
That's because nightlies are broken. The compiler used is actually somewhere between 2.091 and 2.092 : https://run.dlang.io/is/foS0FX Also visible there : http://downloads.dlang.org/nightlies/. There are not even promoted on the main download page, as it used to be.
Oh, what's happening? I thought nightly was nightly :D
They could be restored soon. There's a related PR https://github.com/dlang/dmd/pull/12491, it's not sure if it aims at restoring nighlies. It 90% sure tho.
Thanks for the info!
May 05
prev sibling parent reply Imperatorn <johan_forsberg_86 hotmail.com> writes:
On Wednesday, 5 May 2021 at 09:18:58 UTC, Imperatorn wrote:
 On Wednesday, 5 May 2021 at 08:58:41 UTC, user1234 wrote:
 On Saturday, 1 May 2021 at 11:32:47 UTC, Blatnik wrote:
 I love how D redesigned the terrible C/C++ arrays. And it's 
 awesome that array operations like element wise +, -, etc. 
 are built into the language - it makes me want to use arrays 
 and slices for everything. But there are still some rough 
 edges in the design.
I have experimented some and found a few workarounds which might be acceptable. But, I'm having some weird bug. On dmd and dmd-beta it works, but on dmd-nightly I get: cannot interpret array literal expression [1, 2, 3] + [3, 2, 1] at compile time I think this might be a regression? Like, this works as I want: https://run.dlang.io/is/rHRiP9 If I use dmd or dmd-beta. But if I change it to dmd-nightly it doesn't :( 😒😒😒
Output locally from https://run.dlang.io/is/ZUFFfZ: PS C:\Temp\D\temp> dmd .\arrays.d 2096L PS C:\Temp\D\temp> .\arrays.exe [4, 4, 4] [4, 4, 4] [4, 4, 4] [4, 4, 4] [4, 4, 4] PS C:\Temp\D\temp> ldc2 .\arrays.d 2096L PS C:\Temp\D\temp> .\arrays.exe [4, 4, 4] [4, 4, 4] [4, 4, 4] [4, 4, 4] [4, 4, 4]
May 05
parent reply Imperatorn <johan_forsberg_86 hotmail.com> writes:
On Wednesday, 5 May 2021 at 09:28:45 UTC, Imperatorn wrote:
 On Wednesday, 5 May 2021 at 09:18:58 UTC, Imperatorn wrote:
 On Wednesday, 5 May 2021 at 08:58:41 UTC, user1234 wrote:
 On Saturday, 1 May 2021 at 11:32:47 UTC, Blatnik wrote:
 I love how D redesigned the terrible C/C++ arrays. And it's 
 awesome that array operations like element wise +, -, etc. 
 are built into the language - it makes me want to use arrays 
 and slices for everything. But there are still some rough 
 edges in the design.
I have experimented some and found a few workarounds which might be acceptable. But, I'm having some weird bug. On dmd and dmd-beta it works,
This all works with 2.096.0 and beta but not nightly ```d import std.stdio; immutable ic = [1, 2, 3] + [3, 2, 1]; const ca2 = [1, 2, 3] + [3, 2, 1]; enum ea2 = [1, 2, 3] + [3, 2, 1]; int[] i3 = [1, 2, 3] + [3, 2, 1]; auto a6 = [1, 2, 3] + [3, 2, 1]; void main() { pragma(msg, __VERSION__); auto a = [1, 2, 3]; auto b = [3, 2, 1]; enum ia2 = [1, 2, 3] + [3, 2, 1] + [1, 1, 1]; int[3] d; d = a[] + b[]; writeln(ia2); writeln(ic); writeln(ca2); writeln(ea2); writeln(a6); writeln(d); } ```
May 05
parent user1234 <user1234 12.de> writes:
On Wednesday, 5 May 2021 at 09:33:47 UTC, Imperatorn wrote:
 On Wednesday, 5 May 2021 at 09:28:45 UTC, Imperatorn wrote:
 On Wednesday, 5 May 2021 at 09:18:58 UTC, Imperatorn wrote:
 On Wednesday, 5 May 2021 at 08:58:41 UTC, user1234 wrote:
 On Saturday, 1 May 2021 at 11:32:47 UTC, Blatnik wrote:
 I love how D redesigned the terrible C/C++ arrays. And it's 
 awesome that array operations like element wise +, -, etc. 
 are built into the language - it makes me want to use 
 arrays and slices for everything. But there are still some 
 rough edges in the design.
I have experimented some and found a few workarounds which might be acceptable. But, I'm having some weird bug. On dmd and dmd-beta it works,
This all works with 2.096.0 and beta but not nightly
lol, nightlies are not updated since 13 monthes... https://forum.dlang.org/post/avkkqfjtfrwtmnvpxbot forum.dlang.org
May 05