DIP 1020--Named Parameters--Community Review Round 2

[Walter Bright]

On 9/10/2019 10:37 PM, rikki cattermole wrote:
> On 11/09/2019 9:10 AM, Walter Bright wrote:
>> 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 
> 
> I stand by my question.
> In your proposal there was no mention of template support.
> 
> You have since

The same day.


> said what your strategy is for templates.
> 
> https://digitalmars.com/d/archives/digitalmars/D/DIP_1020--Named_Parameters--Community_Review_Round_1_325299.html#N325650 

Which was simply "Same problem, same solution".


> However I disagree with your rationale.

My suggestion is the leading alternative to yours, and the DIP needs to address 
it. The DIP gives no rationale for why reordering is undesirable (a link to an 
argument is not enough), as that question will interminably come up, and needs 
to be solid. It needs to justify being different from the struct literal syntax, 
because being different (and less capable) is almost guaranteed to be a source 
of problems. (In particular, struct literals and function calls cannot become a 
unified syntax, as they almost are today.)