digitalmars.dip.ideas - Allow designated initialization of struct

ryuukk_ (11/11) Aug 30 This should be allowed:

ryuukk_ (4/4) Aug 30 And in a perfect world:

f (7/11) Nov 01 this is perhaps c# syntax that allows ease of typing.

monkyyy (21/32) Aug 30 the debate is about nested stucts being spooky
Steven Schveighoffer (19/30) Aug 30 I'm not understanding the `@disable this()`

ryuukk_ (27/59) Aug 30 brackets vs parenthesis, no ctor

ryuukk_ (44/44) Sep 12 Today i tried this:

Sergey (20/38) Sep 12 ```d

ryuukk_ (12/58) Sep 12 What did i expect?.. right i expect to switch language as soon as

ryuukk_ (3/3) Sep 12 and please, ask yourself, what the fuck is that error message to
Serg Gini (3/8) Sep 12 I see now what you want. Wasnt clear for me from the first look.

ryuukk_ (2/3) Sep 12 I'm not sure if you are joking or not, i'll pretend this was a

Nick Treleaven (8/27) Sep 13 You are passing a struct literal to `add`. A struct literal is an

ryuukk_ (4/35) Sep 13 This should be allowed, another DIP idea, if anyone still care

IchorDev (16/60) Nov 02 The [struct static initialiser

ryuukk_ (9/9) Oct 21 https://x.com/SebAaltonen/status/1848311998376738892/

Salih Dincer (89/92) Oct 25 I care but is there not enough development? I claim that D is a

ryuukk_ (13/107) Oct 30 No this is not the same thing

Salih Dincer (8/12) Oct 30 I don't think like you. Already with ImportC, D has achieved a

ryuukk_ (67/79) Nov 01 Ok let's try it this way:

IchorDev (10/12) Nov 02 Nope, not even close. That medal has to go to integer promotion.

Nick Treleaven (4/9) Nov 02 Actually that example compiles fine due to VRP.

Salih Dincer (23/40) Nov 03 You want that magic in C and more. But D is a much more stable

ryuukk_ <ryuukk.dev gmail.com> writes:

This should be allowed:

```D
struct Data
{
     int a;
     int b;
     int c;
      disable this();
}

my_fun( Data { c: 1 } );
```

Aug 30

ryuukk_ <ryuukk.dev gmail.com> writes:

And in a perfect world:

```D
my_fun( { c: 1 } );
```

Aug 30

f <f abc.com> writes:

On Friday, 30 August 2024 at 16:03:27 UTC, ryuukk_ wrote:
 And in a perfect world:

 ```D
 my_fun( { c: 1 } );
 ```



which is good to have for d to be modern language.

but the most urgent is perhaps coroutine,
it is only at first draft.

and we have 3 compiler that is not sharp enough. other language 
has only _ONE_ that great. IMHO

Nov 01

monkyyy <crazymonkyyy gmail.com> writes:

On Friday, 30 August 2024 at 16:02:38 UTC, ryuukk_ wrote:
 This should be allowed:

 ```D
 struct Data
 {
     int a;
     int b;
     int c;
      disable this();
 }

 my_fun( Data { c: 1 } );
 ```

the debate is about nested stucts being spooky

```d
struct nullable(T){
   T get; alias get this;
   bool isnull=false;
   ...
}
struct runtime{
   this(int i){
     i.writeln;
}}
nullable!T somethingfailable(T)(T t){
   return nullable!T(isnull:true);
}
```
the compiler gets confused, whats a `somethingfailable.get`?

Im of the strong opinion that d should just let spookiness 
happen, if "ctfe this" fails to produce sane results, thats on 
the programmer, let it happen; but you "need" to "solve" the 
"problem" to suggest changes here.

Aug 30

Steven Schveighoffer <schveiguy gmail.com> writes:

On Friday, 30 August 2024 at 16:02:38 UTC, ryuukk_ wrote:
 This should be allowed:

 ```D
 struct Data
 {
     int a;
     int b;
     int c;
      disable this();
 }

 my_fun( Data { c: 1 } );
 ```


I'm not understanding the ` disable this()`

Without that, this works:

```d
struct Data
{
     int a;
     int b;
     int c;
}

void my_fun(Data data) {}

void main()
{
     my_fun( Data (c: 1 ) );
}
```

I tried making Data also have a ctor with all defaults, but it 
doesn't like that.

-Steve

Aug 30

ryuukk_ <ryuukk.dev gmail.com> writes:

On Friday, 30 August 2024 at 19:37:22 UTC, Steven Schveighoffer 
wrote:
 On Friday, 30 August 2024 at 16:02:38 UTC, ryuukk_ wrote:
 This should be allowed:

 ```D
 struct Data
 {
     int a;
     int b;
     int c;
      disable this();
 }

 my_fun( Data { c: 1 } );
 ```


 I'm not understanding the ` disable this()`

 Without that, this works:

 ```d
 struct Data
 {
     int a;
     int b;
     int c;
 }

 void my_fun(Data data) {}

 void main()
 {
     my_fun( Data (c: 1 ) );
 }
 ```

 I tried making Data also have a ctor with all defaults, but it 
 doesn't like that.

 -Steve

brackets vs parenthesis, no ctor

it's popular among C and newest languages (the irony), data first

D lags behind, as usual

```
     state.pip = sg_make_pipeline(&(sg_pipeline_desc){
         .layout = {
             /* test to provide buffer stride, but no attr offsets 
*/
             .buffers[0].stride = 28,
             .attrs = {
                 [ATTR_vs_position].format = 
SG_VERTEXFORMAT_FLOAT3,
                 [ATTR_vs_color0].format   = SG_VERTEXFORMAT_FLOAT4
             }
         },
         .shader = shd,
         .index_type = SG_INDEXTYPE_UINT16,
         .cull_mode = SG_CULLMODE_BACK,
         .depth = {
             .write_enabled = true,
             .compare = SG_COMPAREFUNC_LESS_EQUAL,
         },
         .label = "cube-pipeline"
     });

```

Aug 30

ryuukk_ <ryuukk.dev gmail.com> writes:

Today i tried this:


```D


struct Test
{
     int test;
}

struct Data
{
     Test[8] test;
}

void add(Data data)
{
}

extern(C) void main()
{
     add( Data(test: [ {test: 1}] ) );
}

```

it refuses to compile:

```
onlineapp.d(19): Error: found `}` when expecting `;` following 
expression
onlineapp.d(19):        expression: `1`
onlineapp.d(19): Error: found `]` instead of statement
onlineapp.d(21): Error: found `End of File` when expecting `,`
onlineapp.d(19): Error: found `End of File` when expecting `]`
onlineapp.d(21): Error: found `End of File` when expecting `)`
onlineapp.d(21): Error: found `End of File` when expecting `)`
onlineapp.d(21): Error: found `End of File` when expecting `;` 
following expression
onlineapp.d(19):        expression: `add(Data(test: [()
{
test:
1;
__error__
}
]))`
onlineapp.d(21): Error: matching `}` expected following compound 
statement, not `End of File`
onlineapp.d(18):        unmatched `{`
```


D worse than C with these stupid RAII, give me proper way to 
initialize a struct instead of giving me a broken constructor i'm 
not even using

Sep 12

Sergey <kornburn yandex.ru> writes:

On Thursday, 12 September 2024 at 12:14:17 UTC, ryuukk_ wrote:
 Today i tried this:


 ```D


 struct Test
 {
     int test;
 }

 struct Data
 {
     Test[8] test;
 }

 void add(Data data)
 {
 }

 extern(C) void main()
 {
     add( Data(test: [ {test: 1}] ) );
 }

 ```

```d
struct Test
{
     int test;
}

struct Data
{
     Test[8] test;
}

void add(Data data)
{
}

extern(C) void main()
{
     add(Data(Test(1).repeat(8).array.to!(Test[8])));
}
```

What did you expect to initializing an array of 8 elements with 1 
value? all the same?

Sep 12

ryuukk_ <ryuukk.dev gmail.com> writes:

On Thursday, 12 September 2024 at 13:10:09 UTC, Sergey wrote:
 On Thursday, 12 September 2024 at 12:14:17 UTC, ryuukk_ wrote:
 Today i tried this:


 ```D


 struct Test
 {
     int test;
 }

 struct Data
 {
     Test[8] test;
 }

 void add(Data data)
 {
 }

 extern(C) void main()
 {
     add( Data(test: [ {test: 1}] ) );
 }

 ```

 ```d
 struct Test
 {
     int test;
 }

 struct Data
 {
     Test[8] test;
 }

 void add(Data data)
 {
 }

 extern(C) void main()
 {
     add(Data(Test(1).repeat(8).array.to!(Test[8])));
 }
 ```

 What did you expect to initializing an array of 8 elements with 
 1 value? all the same?

What did i expect?.. right i expect to switch language as soon as 
i find an alternative


Besides

Test[8] test = Test.init; // <- works

Data data = { test: Test.init }; // <- works

char[256] path = "/dev/null"; // <- works


Again, what do YOU expect?

D people still don't understand why the language is not more 
popular and why people leave after they play with it

I grew tired of trying to explain people how shitty things are 
for so long, wake up please

Sep 12

ryuukk_ <ryuukk.dev gmail.com> writes:

and please, ask yourself, what the fuck is that error message to 
begin with?

broken down to the diagnostics, that's D for you!

Sep 12

Serg Gini <kornburn yandex.ru> writes:

On Thursday, 12 September 2024 at 13:46:55 UTC, ryuukk_ wrote:
 Again, what do YOU expect?

 D people still don't understand why the language is not more 
 popular and why people leave after they play with it

 I grew tired of trying to explain people how shitty things are 
 for so long, wake up please

I see now what you want. Wasnt clear for me from the first look.
Only named example worked yeah

Sep 12

ryuukk_ <ryuukk.dev gmail.com> writes:

 add(Data(Test(1).repeat(8).array.to!(Test[8])));

I'm not sure if you are joking or not, i'll pretend this was a 
mistake of yours

Sep 12

Nick Treleaven <nick geany.org> writes:

On Thursday, 12 September 2024 at 12:14:17 UTC, ryuukk_ wrote:
 ```D
 struct Test
 {
     int test;
 }

 struct Data
 {
     Test[8] test;
 }

 void add(Data data)
 {
 }

 extern(C) void main()
 {
     add( Data(test: [ {test: 1}] ) );
 }

 ```

You are passing a struct literal to `add`. A struct literal is an 
expression:
https://dlang.org/spec/struct.html#struct-literal

 A struct literal consists of the name of the struct followed by 
 a parenthesized named argument list

So `[ {test: 1}]` is parsed as an array literal (because it is an 
expression), not an array intializer. `{test: 1}` in expression 
context is parsed as an invalid function literal (because there's 
no semi-colon).

Sep 13

ryuukk_ <ryuukk.dev gmail.com> writes:

On Friday, 13 September 2024 at 10:55:11 UTC, Nick Treleaven 
wrote:
 On Thursday, 12 September 2024 at 12:14:17 UTC, ryuukk_ wrote:
 ```D
 struct Test
 {
     int test;
 }

 struct Data
 {
     Test[8] test;
 }

 void add(Data data)
 {
 }

 extern(C) void main()
 {
     add( Data(test: [ {test: 1}] ) );
 }

 ```

 You are passing a struct literal to `add`. A struct literal is 
 an expression:
 https://dlang.org/spec/struct.html#struct-literal

 A struct literal consists of the name of the struct followed 
 by a parenthesized named argument list

 So `[ {test: 1}]` is parsed as an array literal (because it is 
 an expression), not an array intializer. `{test: 1}` in 
 expression context is parsed as an invalid function literal 
 (because there's no semi-colon).

This should be allowed, another DIP idea, if anyone still care 
about improving the language

Sep 13

IchorDev <zxinsworld gmail.com> writes:

On Thursday, 12 September 2024 at 12:14:17 UTC, ryuukk_ wrote:
 Today i tried this:


 ```D


 struct Test
 {
     int test;
 }

 struct Data
 {
     Test[8] test;
 }

 void add(Data data)
 {
 }

 extern(C) void main()
 {
     add( Data(test: [ {test: 1}] ) );
 }

 ```

 it refuses to compile:

 ```
 onlineapp.d(19): Error: found `}` when expecting `;` following 
 expression
 onlineapp.d(19):        expression: `1`
 onlineapp.d(19): Error: found `]` instead of statement
 onlineapp.d(21): Error: found `End of File` when expecting `,`
 onlineapp.d(19): Error: found `End of File` when expecting `]`
 onlineapp.d(21): Error: found `End of File` when expecting `)`
 onlineapp.d(21): Error: found `End of File` when expecting `)`
 onlineapp.d(21): Error: found `End of File` when expecting `;` 
 following expression
 onlineapp.d(19):        expression: `add(Data(test: [()
 {
 test:
 1;
 __error__
 }
 ]))`
 onlineapp.d(21): Error: matching `}` expected following 
 compound statement, not `End of File`
 onlineapp.d(18):        unmatched `{`
 ```


 D worse than C with these stupid RAII, give me proper way to 
 initialize a struct instead of giving me a broken constructor 
 i'm not even using

The [struct static initialiser 
syntax](https://dlang.org/spec/struct.html#static_struct_init) 
(using `{}`) is basically a barebones C-compatibility feature, 
and it **only** works when **initialising a variable**. Stop 
expecting it to have any sort of type-inference—Walter thinks 
type-inference is The Devil! It would be nice if we did have type 
inference, and my suggestion was writing the type name for a 
constructor wouldn't be required if the type can be inferred from 
its context (e.g. `add(%(test: [%(test: 1)])`), but doing this 
for arrays is very messy because they infer their type from their 
*contents*, not from where they're being sent. If we had the 
aforementioned constructor type inference, then I wouldn't mind 
even sending the static initialiser syntax to the deprecation 
graveyard, even though I use it heavily in my libraries because 
it predates named parameters.

Nov 02

ryuukk_ <ryuukk.dev gmail.com> writes:

https://x.com/SebAaltonen/status/1848311998376738892/

https://x.com/FlohOfWoe/status/1848357742240518436

https://x.com/SebAaltonen/status/1848336276308554192

https://x.com/FlohOfWoe/status/1848355671554535764

If you want to attract talents, you have to provide them with the 
tools to be at least as productive and efficient as with C

I read, learn and get inspiration from these kind of people

I get rewarded as a result, relatively fast code (i'm still 
improving as i learn), ~0.4s clean build, and 300kb WASM file

Oct 21

Salih Dincer <salihdb hotmail.com> writes:

On Friday, 13 September 2024 at 14:18:28 UTC, ryuukk_ wrote:
 This should be allowed, another DIP idea, if anyone still care 
 about improving the language

I care but is there not enough development? I claim that D is a 
better language than C pluck pluck :)

Isn't the following enough for you?

```d
import std.typecons;

struct Vector3i { uint x, y, z; }

void main()
{
   //Vector3i vector = {z: 3, x: 1, y: 2};/*
   auto vector = Vector3i(
     z: 3,
     x: 1,
     y: 2
   );//*/

   // ...
```

On Monday, 21 October 2024 at 14:02:20 UTC, ryuukk_ wrote:
 https://x.com/SebAaltonen/status/1848311998376738892/

I took implemented the code written by the people you modeled 
without getting lazy:

![Kod](https://pbs.twimg.com/media/GaaE7R6WMAAJkSd?format=jpg&name=4096x4096)

Is the following still not enough? Same code:

```d
   // ...
   ResourceMaker rm;
   auto data = new ubyte[vertexSize];

   auto vertexBuffer = rm.createBuffer(
        debugName: "cube",
        byteSize: vertexSize * vertexAmo,
        usage: Usage.vertex,
        memory: Memory.GPU_CPU
   );

   auto texture = rm.createTexture(
        debugName: "lion.png",
        dimensions: Vector3i(256, 256, 1),
        format: Format.RGBA8_SRGB,
        initialData: cast(ubyte[])data[0..dataSize]
   );

   auto uniforms = vertexBuffer;
   auto material = BindGroup(
        debugName: "Car Paint",
        layout: "materialBindingsLayout",
        textures: ["albedo", "normal", "properties"],
        buffers: [tuple!("buffer", "byteOffset")(uniforms, 64)]
   );
}

enum : uint
{
        dataSize = 128,
        vertexSize = 1024,
        vertexAmo = 8,
}

enum Format { RGBA8_SRGB, RGBA16_FLOAT }
enum Usage { vertex, uniform }
enum Memory { CPU, GPU_CPU }

struct BufferDesc
{
        string debugName = null;
        uint byteSize;
        Usage usage = Usage.uniform;
        Memory memory = Memory.CPU;
        ubyte[] initialData;
}

struct BindGroup
{
        string debugName = null;
        string layout;
        string[] textures;
        Tuple!(BufferDesc, "buffer", int, "byteOffset")[] buffers;
}

struct Texture
{
        string debugName = null;
        Vector3i dimensions;
        Format format = Format.RGBA8_SRGB;
        ubyte[] initialData;
}

struct ResourceMaker
{
   auto createBuffer(uint byteSize, string debugName, Memory 
memory, Usage usage, ubyte[] initialData = [])
     => BufferDesc(debugName, byteSize, usage, memory, 
initialData);

   auto createTexture(string debugName, Vector3i dimensions, 
Format format, ubyte[] initialData = [])
     => Texture(debugName, dimensions, format, initialData);
}
```

SDB 79

Oct 25

ryuukk_ <ryuukk.dev gmail.com> writes:

On Saturday, 26 October 2024 at 00:55:36 UTC, Salih Dincer wrote:
 On Friday, 13 September 2024 at 14:18:28 UTC, ryuukk_ wrote:
 This should be allowed, another DIP idea, if anyone still care 
 about improving the language

 I care but is there not enough development? I claim that D is a 
 better language than C pluck pluck :)

 Isn't the following enough for you?

 ```d
 import std.typecons;

 struct Vector3i { uint x, y, z; }

 void main()
 {
   //Vector3i vector = {z: 3, x: 1, y: 2};/*
   auto vector = Vector3i(
     z: 3,
     x: 1,
     y: 2
   );//*/

   // ...
 ```

 On Monday, 21 October 2024 at 14:02:20 UTC, ryuukk_ wrote:
 https://x.com/SebAaltonen/status/1848311998376738892/

 I took implemented the code written by the people you modeled 
 without getting lazy:

 ![Kod](https://pbs.twimg.com/media/GaaE7R6WMAAJkSd?format=jpg&name=4096x4096)

 Is the following still not enough? Same code:

 ```d
   // ...
   ResourceMaker rm;
   auto data = new ubyte[vertexSize];

   auto vertexBuffer = rm.createBuffer(
        debugName: "cube",
        byteSize: vertexSize * vertexAmo,
        usage: Usage.vertex,
        memory: Memory.GPU_CPU
   );

   auto texture = rm.createTexture(
        debugName: "lion.png",
        dimensions: Vector3i(256, 256, 1),
        format: Format.RGBA8_SRGB,
        initialData: cast(ubyte[])data[0..dataSize]
   );

   auto uniforms = vertexBuffer;
   auto material = BindGroup(
        debugName: "Car Paint",
        layout: "materialBindingsLayout",
        textures: ["albedo", "normal", "properties"],
        buffers: [tuple!("buffer", "byteOffset")(uniforms, 64)]
   );
 }

 enum : uint
 {
        dataSize = 128,
        vertexSize = 1024,
        vertexAmo = 8,
 }

 enum Format { RGBA8_SRGB, RGBA16_FLOAT }
 enum Usage { vertex, uniform }
 enum Memory { CPU, GPU_CPU }

 struct BufferDesc
 {
        string debugName = null;
        uint byteSize;
        Usage usage = Usage.uniform;
        Memory memory = Memory.CPU;
        ubyte[] initialData;
 }

 struct BindGroup
 {
        string debugName = null;
        string layout;
        string[] textures;
        Tuple!(BufferDesc, "buffer", int, "byteOffset")[] 
 buffers;
 }

 struct Texture
 {
        string debugName = null;
        Vector3i dimensions;
        Format format = Format.RGBA8_SRGB;
        ubyte[] initialData;
 }

 struct ResourceMaker
 {
   auto createBuffer(uint byteSize, string debugName, Memory 
 memory, Usage usage, ubyte[] initialData = [])
     => BufferDesc(debugName, byteSize, usage, memory, 
 initialData);

   auto createTexture(string debugName, Vector3i dimensions, 
 Format format, ubyte[] initialData = [])
     => Texture(debugName, dimensions, format, initialData);
 }
 ```

 SDB 79

No this is not the same thing

this is function arguments, it limits what you can do and you 
quickly reach its limits when you want to initialize a struct 
that contains a struct

I already made a forum post about it to complain about how stupid 
this is

I ask for simplicity, i have a struct and i want to construct it, 
no function, no parameters, just simple struct that i can copy 
around

D can do it, it just needs to stop limiting people on purpose, 
again, if it wants to attract the C crowd, it needs to offer 
better, not worse, otherwise people snub D

Oct 30

Salih Dincer <salihdb hotmail.com> writes:

On Wednesday, 30 October 2024 at 17:02:24 UTC, ryuukk_ wrote:
 
 D can do it, it just needs to stop limiting people on purpose, 
 again, if it wants to attract the C crowd, it needs to offer 
 better, not worse, otherwise people snub D

I don't think like you. Already with ImportC, D has achieved a 
great superiority. I mean, it's not like you said, because 
they're coming in droves :) This video was a harbinger of this, 
and 2 years have passed and the D language has matured a lot. I 
can't even think about 2 years from now. Wonderful

https://youtu.be/2ImfbGm0fls?si=_IZDi5bxfwLoMNBv

SDB 79

Oct 30

ryuukk_ <ryuukk.dev gmail.com> writes:

On Thursday, 31 October 2024 at 06:24:44 UTC, Salih Dincer wrote:
 On Wednesday, 30 October 2024 at 17:02:24 UTC, ryuukk_ wrote:
 
 D can do it, it just needs to stop limiting people on purpose, 
 again, if it wants to attract the C crowd, it needs to offer 
 better, not worse, otherwise people snub D

 I don't think like you. Already with ImportC, D has achieved a 
 great superiority. I mean, it's not like you said, because 
 they're coming in droves :) This video was a harbinger of this, 
 and 2 years have passed and the D language has matured a lot. I 
 can't even think about 2 years from now. Wonderful

 https://youtu.be/2ImfbGm0fls?si=_IZDi5bxfwLoMNBv

 SDB 79

Ok let's try it this way:


```D
struct Other
{
     int a;
}

struct Data
{
     Other other;
}

void pass(Data data)
{
}
void main()
{

     // THIS OK
     Data data = {
         other: { a: 42 }
     };

     // THIS OK
     pass( Data(other: Other(a: 42)));


     // WHY THIS NOT OK??
     // pass( Data { other: {a: 42} } );

     // WHY THIS NOT OK??
     //pass( Data(other: {a: 42}));
}
```


Why limit for no reason what you can do with D

Why force people to repeat themselves `other: Other(a: 42)`?


This is the thing D does worse than all of the competition that 
aim to replace C, even C3 does better... C3...


```C

struct Other
{
     int value;
}

struct Data
{
     Other[] other;
}

fn void pass(Data data)
{
}

fn void main()
{
     pass( { .other = { {.value=42} } } );
}

```

This builds

This also build:

```C
enum State
{
     IDLE,
     RUN,
     ATTACK,
}


fn void main()
{
     State state = IDLE;
     if (state == RUN) {
         // run
     }
}
```

D needs to to better

Nov 01

IchorDev <zxinsworld gmail.com> writes:

On Friday, 1 November 2024 at 12:26:25 UTC, ryuukk_ wrote:
 This is the thing D does worse than all of the competition that 
 aim to replace C

Nope, not even close. That medal has to go to integer promotion.
```d
short x = 127;
short y = x / 2 + 1; //Error: integer promotion screwed you over 
again!
//ugh take two:
short y = cast(byte)(x / 2 + 1);
```
Heaven forbid you work with `short` or `byte` on a regular basis.

Nov 02

Nick Treleaven <nick geany.org> writes:

On Saturday, 2 November 2024 at 18:01:45 UTC, IchorDev wrote:
 Nope, not even close. That medal has to go to integer promotion.

That seems off-topic for this DIP thread.

 ```d
 short x = 127;
 short y = x / 2 + 1; //Error: integer promotion screwed you 
 over again!

Actually that example compiles fine due to VRP.
https://dlang.org/spec/type.html#vrp

Nov 02

Salih Dincer <salihdb hotmail.com> writes:

On Friday, 1 November 2024 at 12:26:25 UTC, ryuukk_ wrote:
 
 ```C
 enum State
 {
     IDLE,
     RUN,
     ATTACK,
 }


 fn void main()
 {
     State state = IDLE;
     if (state == RUN) {
         // run
     }
 }
 ```

 D needs to to better

You want that magic in C and more. But D is a much more stable 
language

```C
#include <assert.h>

typedef enum {
   One, Two, Three, Four
} Numbers;

typedef struct {
     size_t counter;
} S;


int main()
{
   assert(Four == 3);
   auto arr[] = { One, Two, Three, Four };

   int Four = 43;
   S myStruct = {
     counter : Four
   };
   assert(myStruct.counter == 43);
}
```

SDB 79

Nov 03

D Programming

C/C++ Programming

Other

digitalmars.dip.ideas - Allow designated initialization of struct