DIP 1019--Named Arguments Lite--Community Review Round 2

[FeepingCreature]

On Thursday, 6 June 2019 at 14:18:14 UTC, Exil wrote:
> On Thursday, 6 June 2019 at 13:47:57 UTC, FeepingCreature wrote:
>> On Thursday, 6 June 2019 at 13:13:45 UTC, Exil wrote:
>>> On Wednesday, 5 June 2019 at 21:24:35 UTC, FeepingCreature 
>>> wrote:
>>>> On Wednesday, 5 June 2019 at 15:25:52 UTC, Exil wrote:
>>>>> I also don't see anywhere that this wouldn't be allowed?
>>>>
>>>> Yes.
>>>>
>>> That wasn't a yes or no question...
>>
>> Yes, this would be allowed in the spec as it stands.
>
> Bit of a nitpick here, I know other people that do the same 
> thing.
>
> If you do want to take it as a question, "This wouldn't be 
> allowed?", answering "yes" means that the feature wouldn't be 
> allowed in the spec. It is the inverse of the question "This 
> would be allowed?", you answer "yes" to this question to have 
> the meaning you intended. The question and it's inverse can't 
> have the same meaning for the same answer.
>

Nitpicking right back: what you said was "I don't see anywhere 
that this wouldn't be allowed". So there's a double negation in 
play; my "yes" was affirming that you don't see it ... because it 
isn't there, because it would be allowed.

> It is not nonsense, if you have a chain of 3 class A -> B -> C
> and in C you need to call > A's method over B's overriden.

Right, the problem is that you can have class A -> B -> C, and 
then you have module D with a void foo(), and in void foo() you 
have a class of C and you want to call A's method. That currently 
works, but it shouldn't, because it overrides C's authority to 
redefine methods from the superclass and makes code very hard to 
follow, because you can't tell which method was called when foo() 
was invoked from looking at the type of the object, you have to 
look at the callsite too.

You can end up with code like

class A
{
   void foo() { bar(); }
   void bar() { }
}

class B : A
{
   void foo() { bar(); }
   void bar() { }
}

B b = new B;
b.A.foo();

So in B.bar(), you cannot assume you were even called from 
B.foo()! There's just no reason to permit shenanigans of this 
degree of inanity.

> Was there even anyone arguing against allowing named parameters 
> to be used with default parameters?

Then I don't see any reason to include in this spec concessions 
to people who would disagree with the spec regardless. I don't 
think there's an argument on the merits to not permit skipping 
default parameters.