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
