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
[DIP] In-place struct initialization
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.
