www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - [DIP] In-place struct initialization

reply cym13 <cpicard openmailbox.org> writes:
In accordance to the new DIP process you can find the full 
presentation of the change here: 
https://github.com/dlang/DIPs/pull/22

This DIP aims at providing better orthogonality and more 
importantly a way to have keyword arguments in the language at 
little cost and great benefit by extending static initialization 
to avoid having to declare a variable. It makes the following 
code legal:

     struct totalArgs {
         int tax;
         int discount;
     }

     int total(int subtotal, totalArgs args = totalArgs.init) {
         return subtotal + args.tax - args.discount;
     }

     unittest {
         assert(total(42) == 42);
         assert(total(42, totalArgs(tax: 50)) == 92);
         assert(total(42, totalArgs(discount: 20, tax: 50)) == 72);

         int defaultTotal(int subtotal) {
             immutable defaultSet = totalArgs(tax: 20);
             return total(subtotal, defaultSet);
         }
     }

Here is the rational as found in the DIP:

Static struct initialization has great properties:

- It is explicit using named attributes
- Order of declaration doesn't matter
- Not all attributes have to be specified

No function call provide those properties, and consequently no 
constructor
can benefit from it either. Authorizing such struct 
initialization makes the
language more orthogonal and opens new doors.

The most interesting is to use structs to mimic keyword arguments 
for
functions. By encapsulating possible arguments in a struct it is 
possible to
use in-place initialization to provide a clean interface very 
similar to
keyword arguments such as seen in python or ruby.

As it stands now the way to provide complex argument set to a 
function is
either to generate lots of constructors for the different cases 
which is
messy or by setting a struct up before passing it to the function 
in a C-way
fashion. This change provides ways to design better high-level 
interfaces.

Besides the change is completely retro-compatible in a nice way: 
the library
itself is just defining an argument struct and using it in its 
function
interface. Code using older compilers can setup the struct 
without in-place
initialization and modern compilers benefit from a cleaner 
interface.

This change also helps interfacing C code that uses structs.


I'm convinced such a change would be great for D but only if 
properly reviewed, please don't hesitate to comment it.
Jul 30 2016
next sibling parent reply Cauterite <cauterite gmail.com> writes:
On Saturday, 30 July 2016 at 21:42:42 UTC, cym13 wrote:

 ...


Here's something you might enjoy in the meantime:
https://github.com/Cauterite/dlang-pod-literals/blob/master/podliterals.d
Jul 30 2016
parent reply cym13 <cpicard openmailbox.org> writes:
On Saturday, 30 July 2016 at 21:45:31 UTC, Cauterite wrote:

 On Saturday, 30 July 2016 at 21:42:42 UTC, cym13 wrote:

 ...


 Here's something you might enjoy in the meantime:
 https://github.com/Cauterite/dlang-pod-literals/blob/master/podliterals.d


Thanks, I'm aware of this work but some points just aren't good 
enough IMHO. We can do better than that. First of all the syntax 
is too far appart from traditional field assignment which is 
always done using ':' . I understand why it is so but still it 
makes one more thing to remember. Calling lambdas all the time 
isn't free while the change I propose is static. Those lambdas 
aren't optimized away by DMD and while that might change I just 
don't feel like trusting it. And more importantly it doesn't work 
with common structs, you have to pass it to your template first 
and then it isn't the struct anymore. There are just too many 
ways for this to get wrong in my opinion.

Note that I find the idea ingenious and interesting, I just think 
we can do better than that.
Jul 30 2016
parent reply Cauterite <cauterite gmail.com> writes:
On Saturday, 30 July 2016 at 22:05:29 UTC, cym13 wrote:

 On Saturday, 30 July 2016 at 21:45:31 UTC, Cauterite wrote:

 On Saturday, 30 July 2016 at 21:42:42 UTC, cym13 wrote:

 ...


 Here's something you might enjoy in the meantime:
 https://github.com/Cauterite/dlang-pod-literals/blob/master/podliterals.d


 Thanks, I'm aware of this work but some points just aren't good 
 enough IMHO. We can do better than that. First of all the 
 syntax is too far appart from traditional field assignment 
 which is always done using ':' . I understand why it is so but 
 still it makes one more thing to remember. Calling lambdas all 
 the time isn't free while the change I propose is static. Those 
 lambdas aren't optimized away by DMD and while that might 
 change I just don't feel like trusting it. And more importantly 
 it doesn't work with common structs, you have to pass it to 
 your template first and then it isn't the struct anymore. There 
 are just too many ways for this to get wrong in my opinion.

 Note that I find the idea ingenious and interesting, I just 
 think we can do better than that.


It does work with common structs:

	struct Xyzº {
		int X;
		wstring Y;
		Object Z;
	};
	auto Thing = pod!(Xyzº,
		Y => `asdf`w,
		X => 3,
		Z => null,
	);

	assert(is(typeof(Thing) == Xyzº));

But anyway, you don't need to convince me that having a native 
language feature would be superior to this template nonsense :P
It's just a workaround for the moment (albeit a bloody powerful 
workaround!)

Although I do like being able to both define and instanciate a 
structure in the same expression (especially with unions). Maybe 
that could be a future extension to your DIP.
Jul 30 2016
parent cym13 <cpicard openmailbox.org> writes:
On Saturday, 30 July 2016 at 22:20:49 UTC, Cauterite wrote:

 On Saturday, 30 July 2016 at 22:05:29 UTC, cym13 wrote:

 [...]


 It does work with common structs:


Sorry, I hadn't noticed.


 But anyway, you don't need to convince me that having a native 
 language feature would be superior to this template nonsense :P
 It's just a workaround for the moment (albeit a bloody powerful 
 workaround!)

 Although I do like being able to both define and instanciate a 
 structure in the same expression (especially with unions). 
 Maybe that could be a future extension to your DIP.


I think it should be a different DIP, while I find the idea 
interesting it doesn't share the same purpose as far as I can 
tell.
Jul 30 2016
prev sibling next sibling parent reply deadalnix <deadalnix gmail.com> writes:
On Saturday, 30 July 2016 at 21:42:42 UTC, cym13 wrote:

 The most interesting is to use structs to mimic keyword 
 arguments for
 functions. By encapsulating possible arguments in a struct it 
 is possible to
 use in-place initialization to provide a clean interface very 
 similar to
 keyword arguments such as seen in python or ruby.


That doesn't help. In fact, it makes things worse as now 
constructor calls and function call do not have the same syntax. 
You've just created an holly mess in the parser.

If something we should strive to get constructor call more like 
regular function call rather than less (for instance by behaving 
the same way when it comes to IFTI).

It is also unclear how overload resolution is supposed to work.

If I may suggest one thing it is to not start with the intended 
result for the DIP, but start from the intended change int he 
language, then, and only then, examine what comes out of it.
Jul 30 2016
next sibling parent reply cym13 <cpicard openmailbox.org> writes:
On Sunday, 31 July 2016 at 04:55:31 UTC, deadalnix wrote:

 On Saturday, 30 July 2016 at 21:42:42 UTC, cym13 wrote:

 The most interesting is to use structs to mimic keyword 
 arguments for
 functions. By encapsulating possible arguments in a struct it 
 is possible to
 use in-place initialization to provide a clean interface very 
 similar to
 keyword arguments such as seen in python or ruby.


 That doesn't help. In fact, it makes things worse as now 
 constructor calls and function call do not have the same 
 syntax. You've just created an holly mess in the parser.

 If something we should strive to get constructor call more like 
 regular function call rather than less (for instance by 
 behaving the same way when it comes to IFTI).

 It is also unclear how overload resolution is supposed to work.

 If I may suggest one thing it is to not start with the intended 
 result for the DIP, but start from the intended change int he 
 language, then, and only then, examine what comes out of it.


I don't understand this comment. This isn't about construction, 
it's about initialization, the call can occur only at one precise 
time and no there is no overload concern as there is no function 
call. The proposed change is litteraly just equivalent to the 
already existing struct initialization, just made usable:

     struct S {
         int a;
         int b;
     }

     auto s = S(b:42);
     // equivalent to
     S s = { b:42 };

Having the possibility to initialize structs without tying them 
to a variable
proves useful when combined with functions that take this struct 
but those
functions aren't directly impacted by the change.
Jul 31 2016
next sibling parent deadalnix <deadalnix gmail.com> writes:
On Sunday, 31 July 2016 at 07:10:46 UTC, cym13 wrote:

 I don't understand this comment.


That's because you haven't tried to specify the grammar. I 
suggest you try.
Jul 31 2016
prev sibling next sibling parent reply Enamex <enamex+d outlook.com> writes:
On Sunday, 31 July 2016 at 07:10:46 UTC, cym13 wrote:

 The proposed change is litteraly just equivalent to the already 
 existing struct initialization, just made usable:

     struct S {
         int a;
         int b;
     }

     auto s = S(b:42);
     // equivalent to
     S s = { b:42 };

 Having the possibility to initialize structs without tying them 
 to a variable
 proves useful when combined with functions that take this 
 struct but those
 functions aren't directly impacted by the change.


I suggest extending the existing `S s = {field: value}` syntax to 
allow specifying the type itself next to the field list and make 
it usable generally everywhere.

So, instead:

takeThing(Thing{ field: val, num: 43 });

It shouldn't clash with anything else, I think.
Jul 31 2016
parent reply Lodovico Giaretta <lodovico giaretart.net> writes:
On Sunday, 31 July 2016 at 13:39:58 UTC, Enamex wrote:

 I suggest extending the existing `S s = {field: value}` syntax 
 to allow specifying the type itself next to the field list and 
 make it usable generally everywhere.

 So, instead:

 takeThing(Thing{ field: val, num: 43 });

 It shouldn't clash with anything else, I think.


I support this idea of extending curly-brace initializers. It 
would be very useful and less ambiguous than parenthesized 
initializers.

[A thread about this]
http://forum.dlang.org/post/ni0u47$2100$1 digitalmars.com

[An issue about this]
https://issues.dlang.org/show_bug.cgi?id=15692
Jul 31 2016
next sibling parent Patrick Schluter <Patrick.Schluter bbox.fr> writes:
On Sunday, 31 July 2016 at 14:38:33 UTC, Lodovico Giaretta wrote:

 On Sunday, 31 July 2016 at 13:39:58 UTC, Enamex wrote:

 I suggest extending the existing `S s = {field: value}` syntax 
 to allow specifying the type itself next to the field list and 
 make it usable generally everywhere.

 So, instead:

 takeThing(Thing{ field: val, num: 43 });

 It shouldn't clash with anything else, I think.


 I support this idea of extending curly-brace initializers. It 
 would be very useful and less ambiguous than parenthesized 
 initializers.

 [A thread about this]
 http://forum.dlang.org/post/ni0u47$2100$1 digitalmars.com

 [An issue about this]
 https://issues.dlang.org/show_bug.cgi?id=15692


It's strange that D wouldn't support something like that as even 
C (C99) can do it with compound literals (struct s){ .z = "Pi", 
.x = 3, .y = 3.1415 }. It's absolutely possible to pass it to a 
function taking a struct s. You can even take its address with & 
if the fonction take a pointer to a struct. I use it all the time 
on my work project.
Jul 31 2016
prev sibling parent reply deadalnix <deadalnix gmail.com> writes:
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.
Aug 03 2016
next sibling parent reply Enamex <enamex+d outlook.com> writes:
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.


Well, this extended case would fall under "struct literal". And 
personally I'm against starting function literals with just a 
brace (always use `(){...}` instead).
Aug 03 2016
parent deadalnix <deadalnix gmail.com> writes:
On Wednesday, 3 August 2016 at 20:43:25 UTC, Enamex 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.


 Well, this extended case would fall under "struct literal". And 
 personally I'm against starting function literals with just a 
 brace (always use `(){...}` instead).


It doesn't matter that there is already a struct literal syntax, 
and that it also a struct literal syntax, the parser have to 
support both.
It doesn't matter what you like or don't like, the parser have to 
support it.
Aug 03 2016
prev sibling next sibling parent reply ZombineDev <petar.p.kirov gmail.com> writes:
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
Aug 03 2016
parent reply Patrick Schluter <Patrick.Schluter bbox.fr> writes:
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
Aug 03 2016
parent reply ZombineDev <petar.p.kirov gmail.com> writes:
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
}
Aug 04 2016
parent reply ketmar <ketmar ketmar.no-ip.org> writes:
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.
Aug 04 2016
parent reply ZombineDev <petar.p.kirov gmail.com> writes:
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?
Aug 04 2016
next sibling parent reply ketmar <ketmar ketmar.no-ip.org> writes:
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.
Aug 04 2016
parent reply deadalnix <deadalnix gmail.com> writes:
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.
Aug 05 2016
next sibling parent ketmar <ketmar ketmar.no-ip.org> writes:
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. ;-)
Aug 05 2016
prev sibling parent reply Cauterite <cauterite gmail.com> writes:
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?
Aug 08 2016
parent ketmar <ketmar ketmar.no-ip.org> writes:
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
Aug 08 2016
prev sibling parent Chris Wright <dhasenan gmail.com> writes:
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.
Aug 05 2016
prev sibling parent reply Chris Wright <dhasenan gmail.com> writes:
On Wed, 03 Aug 2016 20:30:07 +0000, 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.


q{} strings.
Aug 03 2016
parent ketmar <ketmar ketmar.no-ip.org> writes:
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
Aug 04 2016
prev sibling parent Georgi D <georgid outlook.com> writes:
On Sunday, 31 July 2016 at 07:10:46 UTC, cym13 wrote:

 On Sunday, 31 July 2016 at 04:55:31 UTC, deadalnix wrote:

 On Saturday, 30 July 2016 at 21:42:42 UTC, cym13 wrote:

[...]


 That doesn't help. In fact, it makes things worse as now 
 constructor calls and function call do not have the same 
 syntax. You've just created an holly mess in the parser.

 If something we should strive to get constructor call more 
 like regular function call rather than less (for instance by 
 behaving the same way when it comes to IFTI).

 It is also unclear how overload resolution is supposed to work.

 If I may suggest one thing it is to not start with the 
 intended result for the DIP, but start from the intended 
 change int he language, then, and only then, examine what 
 comes out of it.


 I don't understand this comment. This isn't about construction, 
 it's about initialization, the call can occur only at one 
 precise time and no there is no overload concern as there is no 
 function call. The proposed change is litteraly just equivalent 
 to the already existing struct initialization, just made usable:

     struct S {
         int a;
         int b;
     }

     auto s = S(b:42);
     // equivalent to
     S s = { b:42 };

 Having the possibility to initialize structs without tying them 
 to a variable
 proves useful when combined with functions that take this 
 struct but those
 functions aren't directly impacted by the change.


I think a feature like this would be very useful especially for 
User Defined Attributes where it is not possible to write:

S s = {b:42}

Being able to write:

 S(b:42) void foo();

would be great. I do not think there is another solution for this 
at the moment.

I am fine with using curly braces as well if it makes the grammar 
more clean.

 S{b:42} void foo();
Aug 11 2016
prev sibling parent Jacob Carlborg <doob me.com> writes:
On 2016-07-31 06:55, deadalnix wrote:


 That doesn't help. In fact, it makes things worse as now constructor
 calls and function call do not have the same syntax. You've just created
 an holly mess in the parser.

 If something we should strive to get constructor call more like regular
 function call rather than less (for instance by behaving the same way
 when it comes to IFTI).

 It is also unclear how overload resolution is supposed to work.

 If I may suggest one thing it is to not start with the intended result
 for the DIP, but start from the intended change int he language, then,
 and only then, examine what comes out of it.


I think that there's a confusion here. The suggestion requires that the 
type of the struct is included. In Ruby this is not required (there is 
no named type). I don't see how adding a colon to a struct initializer 
would mess up the grammar.

struct Foo
{
     int a;
     int b;
}

void bar(Foo foo);

bar(Foo(1, 2)); // allowed today
bar(Foo(a: 1, b: 2)); // allowed in this suggestion
bar(a: 1, b: 2); // _not_ allowed in this suggestion

-- 
/Jacob Carlborg
Aug 02 2016
prev sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2016-07-30 23:42, cym13 wrote:

 In accordance to the new DIP process you can find the full presentation
 of the change here: https://github.com/dlang/DIPs/pull/22


I like it. I've already reported an enhancement request [1].

[1] https://issues.dlang.org/show_bug.cgi?id=15692

-- 
/Jacob Carlborg
Aug 02 2016
parent Martin Tschierschke <mt smartdolphin.de> writes:
On Tuesday, 2 August 2016 at 16:02:21 UTC, Jacob Carlborg wrote:

 On 2016-07-30 23:42, cym13 wrote:

 In accordance to the new DIP process you can find the full 
 presentation
 of the change here: https://github.com/dlang/DIPs/pull/22


 I like it. I've already reported an enhancement request [1].

 [1] https://issues.dlang.org/show_bug.cgi?id=15692


I am still a D newbie, but would like to vote it up!
Aug 03 2016