[DIP] In-place struct initialization

Patrick Schluter via Digitalmars-d digitalmars-d at puremagic.com
Wed Aug 3 22:15:56 PDT 2016


On Wednesday, 3 August 2016 at 21:35:58 UTC, ZombineDev wrote:
> On Wednesday, 3 August 2016 at 20:30:07 UTC, deadalnix wrote:
>> On Sunday, 31 July 2016 at 14:38:33 UTC, Lodovico Giaretta 
>> wrote:
>>> I support this idea of extending curly-brace initializers. It 
>>> would be very useful and less ambiguous than parenthesized 
>>> initializers.
>>>
>>
>> Curly braces are already extremely overloaded. They can start 
>> a block statement, a delegate literal, a struct literal and 
>> I'm sure I forgot something.
>
> Is there a better choice? StructInitializer [1] is already part 
> of the grammar.
> It would be inconsistent to use anything else, e.g.
>
> S x = { a:1, b:2}; // already works
> x = { a:3, b:4};   // why shouldn't this work?
>
> [1]: http://dlang.org/spec/grammar.html#StructInitializer

To come back to C. It doesn't work in C either. The second 
expression is ambiguous as there could be several structs that 
match the initialiser. In the first expression the type is 
deduced from the declaration. That's why the compound literal was 
introduced which is in fact the explicit mention of the type by 
typecasting. So in C the above will become:

S x = { a:1, b:2}; // already works
x = (struct S){ a:3, b:4};   // C99 compound statement
which allows automatically to be passed to a function call
f((struct S){ a:3, b:4});

D has a lot of smart type inference rules but I don't think that 
a little redundancy here or there should be avoided (especially 
since D already has quite a tendency to require a lot of casting).
This said, in C++ compound initialiser are implemented in some 
compiler as extension and are really problematic (object life 
time) and it would be probably similar in D


More information about the Digitalmars-d mailing list