Re: [DIP] In-place struct initialization
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();
Re: [DIP] In-place struct initialization
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
Re: [DIP] In-place struct initialization
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?
Re: [DIP] In-place struct initialization
On Fri, 05 Aug 2016 06:12:24 +, 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.
Re: [DIP] In-place struct initialization
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. ;-)
Re: [DIP] In-place struct initialization
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.
Re: [DIP] In-place struct initialization
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.
Re: [DIP] In-place struct initialization
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?
Re: [DIP] In-place struct initialization
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.
Re: [DIP] In-place struct initialization
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
Re: [DIP] In-place struct initialization
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 }
Re: [DIP] In-place struct initialization
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
Re: [DIP] In-place struct initialization
On Wed, 03 Aug 2016 20:30:07 +, 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.
Re: [DIP] In-place struct initialization
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
Re: [DIP] In-place struct initialization
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.
Re: [DIP] In-place struct initialization
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).
Re: [DIP] In-place struct initialization
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.
Re: [DIP] In-place struct initialization
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!
Re: [DIP] In-place struct initialization
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
Re: [DIP] In-place struct initialization
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
Re: [DIP] In-place struct initialization
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.
Re: [DIP] In-place struct initialization
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
Re: [DIP] In-place struct initialization
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.
Re: [DIP] In-place struct initialization
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.
Re: [DIP] In-place struct initialization
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.
Re: [DIP] In-place struct initialization
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.
Re: [DIP] In-place struct initialization
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.
Re: [DIP] In-place struct initialization
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.
Re: [DIP] In-place struct initialization
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.
Re: [DIP] In-place struct initialization
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