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

[Exil]

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?
>>
>>    void fun( int a, int b );
>>    fun( a: 0, 10 );
>>
>
> Yes.

That wasn't a yes or no question...

>> The description shows this:
>>
>>     void drawRect(int x, int y, int width, int height);
>>
>>     drawRect(x: 0, y: 0, width: 1, height: 1);
>>     drawRect(0, 0, width: 1, height: 1); // Also valid
>>
>> But there is nothing in the DIP that states that this is valid 
>> or what rules it needs to follow? Like above with the named 
>> parameter appearing before arguments or inbetween.
>>
>
> Named arguments in this proposal are not positional parameters, 
> they're more annotations. The ordinary order of parameters 
> needs to be respected. (That's what makes it "Lite".) That's 
> also why you can't skip default parameters.

It should still specify the rules for which it has to follow, 
which it doesn't currently.

The DIP states that it doesn't prevent a future DIP from allowing 
reordering and default parameters. But if this DIP is implemented 
it will become extremely difficult to implement such a feature in 
the future. It needs to go into detail why this feature isn't 
being included. I feel like because this is "Lite" is not a 
sufficient answer. You only get one chance to implement a feature 
like this, once it is in, there is not going to be changing it. 
If something is going to be excluded it should have a valid 
reason behind why it is not included.

>> https://run.dlang.io/is/eQ7X4p
>>
>> import std.stdio;
>>
>> class A {
>>     void a(int x) { writeln("A"); }
>>  }
>> class B : A {
>>     override void a(int z) { writeln("B"); }
>> }
>>
>> void main() {
>>  	auto b = new B;
>>
>>     b.A.a( 10 );
>>     b.a( 10 );
>> }
>
> This "feature" is nonsense and should be removed. It goes 
> against the entire point of function overriding. It's also not 
> in the spec.
>
> What is in the spec is the ability to do this with fields, ie. 
> "int a" in B hiding "int a" in A, and I suspect this is a side 
> effect of that feature. (Which makes sense, for fields, as 
> field hiding is fundamentally different from method 
> overriding.) Strictly speaking the spec says "members of a base 
> class", but I strongly hope the use for methods is 
> unintentional.

Wouldn't make sense if you couldn't access all members of a base 
class. A method is a member of a class. Also the spec is outdated 
and incorrect in a lot of aspects.