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
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
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 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
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
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).
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
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
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
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
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
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
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
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
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
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
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
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].
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
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
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,
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
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
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.
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
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
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
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:
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
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
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
31 matches
Mail list logo
