Jump to page: 1 217  
Page
Thread overview
DIP 1030--Named Arguments--Community Review Round 1 Discussion
Feb 06
Lim
Feb 06
Lim
Feb 06
Lim
Feb 06
Lim
Feb 06
Lim
Feb 06
Dennis
Feb 07
Piotrek
Feb 07
bachmeier
Feb 07
matheus
Feb 07
matheus
Feb 07
matheus
Feb 07
bachmeier
6 days ago
Paul Backus
6 days ago
aliak
6 days ago
SashaGreat
6 days ago
Sasha
6 days ago
Paul Backus
6 days ago
Jonathan Marler
6 days ago
Sasha
6 days ago
JN
6 days ago
Jonathan Marler
6 days ago
Walter Bright
6 days ago
Walter Bright
5 days ago
Adam D. Ruppe
4 days ago
Walter Bright
Feb 10
rb3
Feb 10
rb3
Feb 09
Zoadian
Feb 09
Arine
6 days ago
Walter Bright
Feb 11
Arine
Feb 10
Panke
Feb 07
jmh530
Feb 10
Manu
Feb 10
Manu
Feb 10
Manu
Feb 10
Manu
Feb 10
jmh530
Feb 11
Arine
Feb 11
Manu
5 days ago
Arine
Feb 11
Claude
Feb 10
Manu
Feb 11
aliak
Feb 10
IGotD-
Feb 10
Manu
Feb 11
aliak
Feb 11
aliak
Feb 11
Manu
Feb 11
Manu
6 days ago
SashaGreat
February 06
This is the feedback thread for the first round of Community Review for DIP 1030, "Named Arguments":

https://github.com/dlang/DIPs/blob/44b0d4ec0da6a2e797ede748fb1e81cd6db10371/DIPs/DIP1030.md

Here in the discussion thread, you are free to discuss anything and everything related to the DIP. Express your support or opposition, debate alternatives, argue the merits... in other words, business as usual.

However, if you have any specific feedback for how to improve the the proposal itself, then please post it in the feedback thread. The feedback thread will be the source for the review summary I write at the end of this review round. I will post a link to that thread immediately following this post. Just be sure to read and understand the Reviewer Guidelines before posting there:

https://github.com/dlang/DIPs/blob/master/docs/guidelines-reviewers.md

The review period will end at 11:59 PM ET on February 20, or when I make a post declaring it complete. Discussion in this thread may continue beyond that point.

At the end of Round 1, if further review is deemed necessary, the DIP will be scheduled for another round of Community Review. Otherwise, it will be queued for the Final Review and Formal Assessment.

Please stay on topic here. I will delete posts that are completely off topic.

February 06
On Thursday, 6 February 2020 at 06:08:59 UTC, Mike Parker wrote:

>
> However, if you have any specific feedback for how to improve the the proposal itself, then please post it in the feedback thread.

The feedback thread is here:

https://forum.dlang.org/post/bizqhxszbobynrimsgai@forum.dlang.org
February 06
On Thursday, 6 February 2020 at 06:08:59 UTC, Mike Parker wrote:
> This is the feedback thread for the first round of Community Review for DIP 1030, "Named Arguments":

What about UFSC + named arguments?

Andrea
February 06
On 2/6/20 4:39 AM, Andrea Fontana wrote:
> On Thursday, 6 February 2020 at 06:08:59 UTC, Mike Parker wrote:
>> This is the feedback thread for the first round of Community Review for DIP 1030, "Named Arguments":
> 
> What about UFSC + named arguments?

Responding to this and the one in the feedback thread.

My understanding is that UFCS works like this:

a.foo(...);

translates to:

foo(a, ...);

So if you follow that logic, the rules apply after that translation as if you called the function that way.

example:

void doStuff(int a, string b, double c) {}

3.doStuff(6.7, b: "ham") => doStuff(3, 6.7, b: ham) => error, no match (6.7 doesn't match type to b)

3.doStuff(c: 6.7, b: "ham") => doStuff(3, c: 6.7, b: ham) => OK, all parameters match

3.doStuff(a: 5, "ham", 6.7) => doStuff(3, a: 5, "ham", 6.7) => error, cannot match a twice

Might be a good point to add UFCS discussion to the DIP.

-Steve
February 06
On Thursday, 6 February 2020 at 15:30:40 UTC, Steven Schveighoffer wrote:
> On 2/6/20 4:39 AM, Andrea Fontana wrote:
> Might be a good point to add UFCS discussion to the DIP.
>
> -Steve

I wonder whether or not "(c: 3).doStuff(3,4);" could be useful... Probably it just adds some noise.
February 06
On Thu, Feb 06, 2020 at 05:03:06PM +0000, Andrea Fontana via Digitalmars-d wrote:
> On Thursday, 6 February 2020 at 15:30:40 UTC, Steven Schveighoffer wrote:
> > On 2/6/20 4:39 AM, Andrea Fontana wrote:
> > Might be a good point to add UFCS discussion to the DIP.
[...]
> I wonder whether or not "(c: 3).doStuff(3,4);" could be useful...
> Probably it just adds some noise.

IMO it not only adds noise, it opens the door for expanding UFCS far beyond its original charter. Because now, nothing stops you from doing this:

	struct A {}
	struct B {}
	struct C {}

	auto fun(A a, B b, C c) { ... }

	A a;
	B b;
	C c;

	(a: a).fun(b: b, c: c);
	(b: b).fun(a: a, c: c);
	(c: c).fun(a: a, b: b);

IOW, you can now pull out any arbitrary parameter from any function and do UFCS on it.  I honestly don't think this is a good idea, as it will open up whole cans o' worms esp. once it starts interacting with IFTI.


T

-- 
We are in class, we are supposed to be learning, we have a teacher... Is it too much that I expect him to teach me??? -- RL
February 06
On Thursday, 6 February 2020 at 17:03:06 UTC, Andrea Fontana wrote:
> On Thursday, 6 February 2020 at 15:30:40 UTC, Steven Schveighoffer wrote:
>> On 2/6/20 4:39 AM, Andrea Fontana wrote:
>> Might be a good point to add UFCS discussion to the DIP.
>>
>> -Steve
>
> I wonder whether or not "(c: 3).doStuff(3,4);" could be useful... Probably it just adds some noise.

Remmeber, UFCS is only tried when property lookup fails. Since `(c: 3).doStuff` is not a valid property access, it cannot possibly be a valid UFCS call.
February 06
On 2/6/2020 7:30 AM, Steven Schveighoffer wrote:
> Might be a good point to add UFCS discussion to the DIP.

Your analysis is correct and inevitable and doesn't need discussion in the DIP. It's another illustration why lowering is a good idea - it takes care of things like this renderubg further exposition and design work not necessary.

February 06
On Thursday, 6 February 2020 at 06:08:59 UTC, Mike Parker wrote:
> This is the feedback thread for the first round of Community Review for DIP 1030, "Named Arguments"

How about template arguments? Can we still omit the parentheses if it is one token long?

i.e., template Example(int a = 0, alias b, int c = 0) => Example!b:1

If the answer is yes, considering the following code:

template SomeTemplate(int a = 0, alias b, int c = 0)
{
    alias SomeTemplate = b;
}

const b = 2;
const c = 3;

switch(someInt)
{
    case 1: .. case SomeTemplate!b : c: writeln("we are in case"); break;
    default: writeln("we are in default"); goto c;
}


It's valid now and when someInt >= 3, "we are in default" and "we are in case" will both be printed.

According to the rule "If an Identifier is present, it matches the Parameter with the corresponding Identifier", when this DIP come into power, this code won't compile as there is no LabeledStatement Identifier named c.

Is this a potential compatibility issue? Or is there a misunderstanding of my interpretation of the new DIP?
February 06
On Thursday, 6 February 2020 at 21:06:38 UTC, Lim wrote:
> template SomeTemplate(int a = 0, alias b, int c = 0)

Should be:
template SomeTemplate(alias b, int c = 0)
« First   ‹ Prev
1 2 3 4 5 6 7 8 9 10 11