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

[Exil]

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

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.

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

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. You do 
so using the same syntax. A.foo(). It would be worse if you have 
some code that you couldn't access and now you need some kind of 
a hack just to access it. Anyways this is getting off topic.

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

Was there even anyone arguing against allowing named parameters 
to be used with default parameters? I've only seen people asking 
for the feature, like yourself. The people arguing against the 
feature are those that simply don't want the feature at all 
because they don't want to have to worry about renaming function 
parameters. That's the only argument I've seen. I haven't heard 
one against allow default parameters to be used as they were 
intended, specifically.