DIP 1031--Deprecate Brace-Style Struct Initializers--Community Review Round 1 Discussion

[Thomas Brix]

On Friday, 14 February 2020 at 07:54:56 UTC, Mathias Lang wrote:
> The real inconvenience shows up as you nest structure, which 
> was in the second part of the quote.
>
> Consider `auto f = Foo(a: SomeType(b: SomeOtherType(x: 42)));`, 
> it is not quite as readable as the struct literal alternative, 
> and there's no way to use `auto` here, even though the expected 
> type is known to the compiler and unambiguous.
>
> And I didn't even mention templates! Imagine if a struct is an 
> aggregate of other templated struct, e.g. `struct Aggregated 
> (T, TV = DefaultValue) { Foo!T f1; Bar!T f2; xvector!(T, TV) 
> f3; }`.
> Have fun turning a struct literal for this into something that 
> spells out the type.
>
> I usually keep my type names verbose but my fields name short, 
> and use struct literal all over the place. It leads to 
> expressive code that is easy to read and easy to write, and 
> feels familiar to people used to read JSON or YAML.
>

Perhaps declarative programming should be a first class feature, 
instead of using struct initializers to emulate it.

The syntax could be similar to QML/DML:

struct Type
{
     string field1;
     string field2;
     NestedField field3;

     struct NestedField
     {
         int field1;
     }
}

struct AnotherType
{
     int field1;
}

declare instance1 : Type
{
     field1: "value";
     field2: "value2";
     field3.field1: 100;
     int field4: 5;

     AnotherType {
         field1: outer.field4 + 9;
     }
}

Lowers to something like:
struct __instance1
{
     Type __type;
     alias type this;
     AnotherType __child_0;
     __constructor() {
         __type.field1 = "value";
         __type.field2 = "value2";
         __type.field3.field1 = 100;
         __child_0.field1 = __type.field4 + 9;
     }
}
__instance1 instance1;