On 13/09/2019 2:51 AM, a11e99z wrote:
> how and why @named should be involved in mangled names and method selection?

They don't.

On 9/10/19 5:10 PM, Walter Bright wrote:
> On 9/10/2019 2:06 AM, Mike Parker wrote:
>> This is the feedback thread for the second round of Community Review for DIP 1020, "Named Parameters":
>>
>> https://github.com/dlang/DIPs/blob/c723d8f4e3ac2d5bcaf8cdff87e1507f09669ca6/DIPs/DIP1020.md 
> 
> 
> My review is the same as in the first round:
> 
> https://digitalmars.com/d/archives/digitalmars/D/DIP_1020--Named_Parameters--Community_Review_Round_1_325299.html#N325627 
> 
> 
> To which Rikki responded with:
> 
> "That solves function arguments, what is your proposal for templates?"
> 
> https://digitalmars.com/d/archives/digitalmars/D/DIP_1020--Named_Parameters--Community_Review_Round_1_325299.html#N325631 

Same here. Whoever wants to take Walter's proposal toward completion of a DIP would do a great service to the community.

On Thursday, 12 September 2019 at 14:36:09 UTC, rikki cattermole wrote:
> On 13/09/2019 1:44 AM, Yuxuan Shui wrote:
>> On Thursday, 12 September 2019 at 12:06:47 UTC, rikki cattermole wrote:
>>> On 12/09/2019 11:50 PM, Yuxuan Shui wrote:
>>>> On Thursday, 12 September 2019 at 11:46:46 UTC, rikki cattermole wrote:
>>>>> [...]
>>>>
>>>> Ah, sorry. I meant to write draw(shape: someShape).
>>>
>>> In that case, two methods:
>>>
>>> 1. void draw(Shape)(@named Shape shape) { draw(shape); }
>>>
>>> 2. void draw(Shape:Circle)(@named Shape shape) { draw(shape); }
>>>
>>> The second is better because of validating the parameter type, but does require one per type. Assuming I remember this particular bit of templates correctly.
>>>
>>> I had to assume that drawing has to be specific to the type passed in and that the draw function will be concrete (can be virtual). But that shouldn't be a problem.
>> 
>> Sorry, I don't think I understand your answer. My question has nothing to do with templates.
>
> To get the functionality you asked about, I had to use templates.
>
> To support overloading on named parameters would require invasive changes and adding a new mangling sequence. Things I want to avoid.
>
> a11e99z asked a similar question under your own in this part of the thread tree. Same answer.

No, I am not asking for overloading based on name. The two functions are clearly distinct based purely on parameter types.

I think this basically means you cannot create functions with only @named parameters. I consider this a pretty serious limitation.

On 13/09/2019 6:00 AM, Yuxuan Shui wrote:
> On Thursday, 12 September 2019 at 14:36:09 UTC, rikki cattermole wrote:
>> On 13/09/2019 1:44 AM, Yuxuan Shui wrote:
>>> On Thursday, 12 September 2019 at 12:06:47 UTC, rikki cattermole wrote:
>>>> On 12/09/2019 11:50 PM, Yuxuan Shui wrote:
>>>>> On Thursday, 12 September 2019 at 11:46:46 UTC, rikki cattermole wrote:
>>>>>> [...]
>>>>>
>>>>> Ah, sorry. I meant to write draw(shape: someShape).
>>>>
>>>> In that case, two methods:
>>>>
>>>> 1. void draw(Shape)(@named Shape shape) { draw(shape); }
>>>>
>>>> 2. void draw(Shape:Circle)(@named Shape shape) { draw(shape); }
>>>>
>>>> The second is better because of validating the parameter type, but does require one per type. Assuming I remember this particular bit of templates correctly.
>>>>
>>>> I had to assume that drawing has to be specific to the type passed in and that the draw function will be concrete (can be virtual). But that shouldn't be a problem.
>>>
>>> Sorry, I don't think I understand your answer. My question has nothing to do with templates.
>>
>> To get the functionality you asked about, I had to use templates.
>>
>> To support overloading on named parameters would require invasive changes and adding a new mangling sequence. Things I want to avoid.
>>
>> a11e99z asked a similar question under your own in this part of the thread tree. Same answer.
> 
> No, I am not asking for overloading based on name. The two functions are clearly distinct based purely on parameter types.
> 
> I think this basically means you cannot create functions with only @named parameters. I consider this a pretty serious limitation.

You can create functions with just @named parameters, but you can't use overloading with them.

Its a side effect of not touching symbol+overload resolution.

Keep in mind that the syntax:

void draw(Shape:Circle)(@named Shape shape)

will allow you to have multiple functions named the same thing with @named parameters. So its not as serious as it may first seem IMO.

On Wednesday, 11 September 2019 at 23:01:32 UTC, Walter Bright wrote:
> On 9/11/2019 12:18 AM, rikki cattermole wrote:
>> But I need to confirm with you before I do this, is this for the replacement of in place struct initialization syntax?
>> 
>> If so I want to solve that, but I need to ask you how you would want it done. Since it touches upon .init, it makes me a little concerned because of dragons.
>
> I'm planning to replace:
>
>   struct S { int a, b; }
>
>   S s = { 1, 2 };
>
> with:
>
>   S s = S(1, 2);
>
> D is almost there already, but is missing the named parameter feature to go all the way.
>
> I'm looking at other ways as well to unify and thereby simplify D.

While this solves some issues, I see one major drawback. This example looks currently very dense. With the new syntax it becomes more verbose because you have to name the structures:

struct PutItemRequest
{
    string tableName;
    AttributeValue[string] item;
}

struct AttributeValue
{
    bool BOOL;
    string S;
    AttributeValue[string] M;
    string[] SS;
}

void main()
{
    PutItemRequest request = {
	    tableName: "table1",
		item: [
		    "field1": {S: "LALA"},
			"field2": {SS: ["A", "B", "C"]},
			"field3": {
			    M: ["fieldA": {S: "234"}]
			}
		]
	};
}

This example is from the Amazon Web Services library I am using. It is rather small. Other calls uses more deep structures.

Also please note, it doesn't compile today because you can use struct initialization today only for arrays but not for associative arrays.

Kind regards
Andre

I'm going to be blunt, so shields up!

For DIP 1020 and DIP 1019, I keep trying to nudge things in the direction of a better design:

https://digitalmars.com/d/archives/digitalmars/D/DIP_1020--Named_Parameters--Community_Review_Round_1_325299.html#N325627

All to no avail. It pains me a great deal to see all this effort and discussion going down the drain on designs that are both more complex and inadequate. The authors have exhibited little or no interest in either adopting my suggestions or explaining why theirs are better.

Andrei and Atila have tried as well.

This has gone on long enough. DIP 1019 and 1020 are not going to be approved.

(It is clear that a lot of time was spend on the DIPs, and they are well written and presented. The authors should be proud of them. It's just that we have a better design.)

On Friday, 13 September 2019 at 07:56:38 UTC, Walter Bright wrote:
> I'm going to be blunt, so shields up!
>
> For DIP 1020 and DIP 1019, I keep trying to nudge things in the direction of a better design:
>
> https://digitalmars.com/d/archives/digitalmars/D/DIP_1020--Named_Parameters--Community_Review_Round_1_325299.html#N325627
>
> All to no avail. It pains me a great deal to see all this effort and discussion going down the drain on designs that are both more complex and inadequate. The authors have exhibited little or no interest in either adopting my suggestions or explaining why theirs are better.
>
> Andrei and Atila have tried as well.
>
> This has gone on long enough. DIP 1019 and 1020 are not going to be approved.
>
> (It is clear that a lot of time was spend on the DIPs, and they are well written and presented. The authors should be proud of them. It's just that we have a better design.)

Thank you for saying this Walter.  This is going to save so many people so much time.

On Friday, 13 September 2019 at 16:02:48 UTC, Jonathan Marler wrote:
> On Friday, 13 September 2019 at 07:56:38 UTC, Walter Bright wrote:
>> [...]
>
> Thank you for saying this Walter.  This is going to save so many people so much time.

But it was a really good and constructive discussion around! Well done to the authors of the two DIPs. I wish they could find the energy to come up with a new DIP...

On 14/09/2019 5:49 AM, M.M. wrote:
> I wish they could find the energy to come up with a new DIP..
No point on my end.

I may as well explain why I created DIP 1020 officially now that it is dead.

The reason is signatures.



Signatures is a language feature that originates from the ML family of languages.

It is in my opinion the best companion to meta-programming and CTFE you could ever have.

From a runtime perspective it would be a vtable, with method bodies being able to be patched on top of the implementation type (struct or class) so that the interface (signature) could adapt to the implementation silently.

At compile time it would act as a type verifier like isInputRange and friends.

It could infer its template instance type from an implementation with automatic binding named parameters to types and constants of the implementation. Separating the interface elements like the ElementType of an input range from the implementation and allowing some information transfer so it could be passed around at runtime.

The design elements from DIP 1020 that would have allowed for this are not wanted by the community or by Walter.

There is nothing I can do without butchering this concept to make it as powerful as it could have been.



"It is possible to commit no mistakes and still lose. That is not a weakness. That is life." - Jean-Luc Picard

On Friday, 13 September 2019 at 18:29:56 UTC, rikki cattermole wrote:
> On 14/09/2019 5:49 AM, M.M. wrote:
>> I wish they could find the energy to come up with a new DIP..
> No point on my end.
>
> I may as well explain why I created DIP 1020 officially now that it is dead.
>
> The reason is signatures.
> [snip]

I feel like this is an argument you should have made much earlier...like...in the DIP...

You are getting frustrated because others are not seeing your vision (butchering the DIP). However, we are not privy to what you have in the back of your mind (type signatures) without those thoughts being clearly spelled out. People were evaluating DIP 1020 on its merits and Walter's suggestions on its merits. DIP 1020 doesn't mention type signatures and why your version of named parameters enables that pattern. Walter's idea may or may not enable your vision of type signatures (I have no idea without more details...and even then may have no idea), but that was never mentioned as a justification for the DIP.

As an aside, you may also find some of the discussion from the DIP 1023 review thread interesting [1]. Later in the thread, I describe the possibility of using alias templates as types and incorporating Atila's concepts library to provide improved error messages. Of course, there is no run-time component here.

[1] https://forum.dlang.org/thread/dnyqxmgdazczwmmvayjx@forum.dlang.org