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

[FeepingCreature]

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?
>>>
>>>    void fun( int a, int b );
>>>    fun( a: 0, 10 );
>>>
>>
>> Yes.
>>
> That wasn't a yes or no question...

Yes, this would be allowed in the spec as it stands.

> 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.

Since it's a virtual method, accessing it as a base class member 
shouldn't do anything, because it should result in the same 
vtable slot. You don't just access it as a base class member, you 
access it *as a static method reference*. This is nonsense.

> 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.

If you think this proposal would block later work on named 
arguments, this is probably a strong reason against it. My 
impression is that this is very much intended as a "foot in the 
door" for named arguments, to demonstrate that the sky will not 
fall if they are implemented. I agree that as a "named parameters 
for now and forevermore" it is disappointingly sparse. The lack 
of ability to skip default parameters seems particularly 
crippling. Personally, varying the order of parameters doesn't 
matter to me, so if that's the cost of getting named parameters 
I'd pay it happily. But I think the problem in general is that we 
have a variety of proposals, and people have argued for, or 
especially against, parts of those proposals almost 
independently. I don't think it's accurate to say that there's 
"camps" of proposals; rather, almost every part of named 
arguments seems to have people who strenuously disagree and think 
it'll make the language worse - but there's no obvious consensus 
or commonality.

This naturally makes it hard to craft a compromise. I believe 
that Named Arguments Lite is an attempt to guess which set of 
compromises will put off the least people while being acceptable 
to the most and delivering at least some value to everybody who 
wants at least some part of named arguments. For me, the lack of 
ability to skip default arguments is a dealbreaker, particularly 
if accepting this proposal would mean that it would be the face 
of named arguments in D forevermore, but if it was "this or 
literally nothing else ever" I'd be in favor. So I guess the 
question rests on whether if this is rejected, there'll be a "D 
Named Arguments Proper" after. And, uh, looking at "shared", that 
seems unlikely for at least several years. So to me the question 
is "this or nothing", and even though it doesn't solve the main 
usecase I'd want it for (verbose constructors, which *needs* the 
ability to skip default arguments), it is at least better than 
the alternative, which is nothing. Though of course any change 
that would leave the door open for skipping parameters would be 
welcome.