On Thursday, 4 August 2016 at 05:15:56 UTC, Patrick Schluter wrote:
> 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.

Why would there be any ambiguity? It doesn't matter if more than one structs have the syntactically identical initializers, because the intended type is clearly the type of the variable that we're assigning to.

> 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).

Maybe I didn't mention it, but I think that { a: 1, b: 2 } syntax should only be allowed when there is no ambiguity. For example, if a function is overloaded the type would need to be specified to disambiguate the function call:

void f(S1);
void f(S2);

f(S1 { a: 1, b: 2 });

s = S2 { a: 1, b: 2 }; // s's opAssign accepts both S1 and S2

> 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

I would be interested to hear more about that. My (maybe naive) understanding tells me that there shouldn't be any problems:

s = S1 { a: 1, b: 2 };

// would be lowered to:

{
  S1 __tmp1 = { a: 1, b: 2 };
  s.opAssign(__tmp1);
  __tmp1.~this(); // dtor is called as usual
}

So it's up to the authot of the struct to ensure correct application of the RAII idiom, which is not different from:


s = S1(1, 2);

// would be lowered to:

{
  S1 __tmp1 = S1(1, 2);
  s.opAssign(__tmp1);
  __tmp1.~this(); // dtor is called as usual
}

On Thursday, 4 August 2016 at 00:57:16 UTC, Chris Wright wrote:
>> 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.
>
> q{} strings.

this is unambiguous. and, btw, it blocks "inline delegate arguments" syntax (foo{return 42;}). and any other syntax like that.

T_T

On Thursday, 4 August 2016 at 07:22:27 UTC, ZombineDev wrote:
> On Thursday, 4 August 2016 at 05:15:56 UTC, Patrick Schluter wrote:
>> 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
>
> I would be interested to hear more about that. My (maybe naive) understanding tells me that there shouldn't be any problems:

there are: inline structure declaration is broken, see issue 16146. therefore it is clear that inline decl is using compeletely different codepath, not connected with calling struct ctor, and may be called "compiler extension" too.

sorry, i couldn't resist injecting one of my pet bugs here.

On Thursday, 4 August 2016 at 08:23:59 UTC, ketmar wrote:
> On Thursday, 4 August 2016 at 07:22:27 UTC, ZombineDev wrote:
>> On Thursday, 4 August 2016 at 05:15:56 UTC, Patrick Schluter wrote:
>>> 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
>>
>> I would be interested to hear more about that. My (maybe naive) understanding tells me that there shouldn't be any problems:
>
> there are: inline structure declaration is broken, see issue 16146. therefore it is clear that inline decl is using compeletely different codepath, not connected with calling struct ctor, and may be called "compiler extension" too.
>
> sorry, i couldn't resist injecting one of my pet bugs here.

Thanks, for the bug report. It's important that it gets fixed if we're to proceed with this proposal.

I was actually looking for design issues. Assuming this bug gets fixed, and
S s = { a: var1, b: var2 }, becomes equivalent to:
S s = void;
s.a = var1; /* calls s.a postblit if necessary */
s.b = var2; /* calls s.b postblit if necessary */

Are there any *design* problems that I did not foresee, that make my proposal not worthwhile pursuing?

On Friday, 5 August 2016 at 06:12:24 UTC, ZombineDev wrote:
> I was actually looking for design issues. Assuming this bug gets fixed, and
> S s = { a: var1, b: var2 }, becomes equivalent to:
> S s = void;
> s.a = var1; /* calls s.a postblit if necessary */
> s.b = var2; /* calls s.b postblit if necessary */

tbh, i'm not a big fan of "{}" initialization syntax. it looks so out of place for me that i didn't even used it once (the bug i found was from alien code ;-).

besides, all this thread looks like a thing that is curing symptoms for me. by introducing general named arguments support, structure ctors with arbitrary fields comes naturally then (not without some code, but it will *look* naturally).

i.e. names args will allow to call any function like `foo(b:42, a:"hi")`, and then autocreated struct ctors should not be an exception.

sorry for not being constructive, but you asked, and i again can't resist the temptation.

On Friday, 5 August 2016 at 06:27:04 UTC, ketmar wrote:
> besides, all this thread looks like a thing that is curing symptoms for me. by introducing general named arguments support, structure ctors with arbitrary fields comes naturally then (not without some code, but it will *look* naturally).
>
> i.e. names args will allow to call any function like `foo(b:42, a:"hi")`, and then autocreated struct ctors should not be an exception.
>

This ^

Also, there are nice library solution for named argument already.

On Friday, 5 August 2016 at 07:04:55 UTC, deadalnix wrote:
> Also, there are nice library solution for named argument already.

i know. but it is a weird hack involving abusing lambdas for something that should be language's core feature. i did a PoC patch for named args a while ago (and still maintaining it in my fork), and and feels *way* better. ;-)

On Fri, 05 Aug 2016 06:12:24 +0000, ZombineDev wrote:
> I was actually looking for design issues. Assuming this bug gets fixed,
> and S s = { a: var1, b: var2 }, becomes equivalent to:
> S s = void;
> s.a = var1; /* calls s.a postblit if necessary */
> s.b = var2; /* calls s.b postblit if necessary */
> 
> Are there any *design* problems that I did not foresee, that make my proposal not worthwhile pursuing?

Your proposal is convenient because it's easily lowerable. It seems fine as initialization where the LHS must be a variable declaration.

It would add a new edge case if the LHS could be some other expression. Specifically, s.a.postblit could get a reference to s before it's fully initialized, even though assignment looks atomic. You could resolve that by copying everything first and running postblits after.

On Friday, 5 August 2016 at 07:04:55 UTC, deadalnix wrote:
> Also, there are nice library solution for named argument already.

Which ones do you have in mind?

On Monday, 8 August 2016 at 09:57:38 UTC, Cauterite wrote:
> On Friday, 5 August 2016 at 07:04:55 UTC, deadalnix wrote:
>> Also, there are nice library solution for named argument already.
>
> Which ones do you have in mind?

https://github.com/CyberShadow/ae/blob/master/utils/meta/args.d