On Tuesday, 10 September 2019 at 19:50:44 UTC, Jonathan Marler wrote:
> On Tuesday, 10 September 2019 at 19:34:45 UTC, Max Haughton wrote:
>> On Tuesday, 10 September 2019 at 18:47:54 UTC, Jonathan Marler wrote:
>>>     [...]
>>
>> In fact, @public cannot compile as is so that might be a better solution still (bare "public" might require modifying the parser more but it's not my expertise)
>
> Yes using `public` would require a grammar change.  However, the feature requires other grammar changes as well.  Also, using either `public` or `@named` without the feature will result in compilation errors so they're both on the same level in that regard.

https://run.dlang.io/is/r409XD @named (on function parameters) compiles as of today

On Tuesday, 10 September 2019 at 22:57:47 UTC, Max Haughton wrote:
> On Tuesday, 10 September 2019 at 19:50:44 UTC, Jonathan Marler wrote:
>> On Tuesday, 10 September 2019 at 19:34:45 UTC, Max Haughton wrote:
>>> On Tuesday, 10 September 2019 at 18:47:54 UTC, Jonathan Marler wrote:
>>>>     [...]
>>>
>>> In fact, @public cannot compile as is so that might be a better solution still (bare "public" might require modifying the parser more but it's not my expertise)
>>
>> Yes using `public` would require a grammar change.  However, the feature requires other grammar changes as well.  Also, using either `public` or `@named` without the feature will result in compilation errors so they're both on the same level in that regard.
>
> https://run.dlang.io/is/r409XD @named (on function parameters) compiles as of today

You had to define the 'named' symbol. Which means if you compiled a module using it, it wouldn't compile because named wouldn't be defined.

On Tuesday, 10 September 2019 at 23:57:33 UTC, Jonathan Marler wrote:
> On Tuesday, 10 September 2019 at 22:57:47 UTC, Max Haughton wrote:
>> On Tuesday, 10 September 2019 at 19:50:44 UTC, Jonathan Marler wrote:
>>> On Tuesday, 10 September 2019 at 19:34:45 UTC, Max Haughton wrote:
>>>> [...]
>>>
>>> Yes using `public` would require a grammar change.  However, the feature requires other grammar changes as well.  Also, using either `public` or `@named` without the feature will result in compilation errors so they're both on the same level in that regard.
>>
>> https://run.dlang.io/is/r409XD @named (on function parameters) compiles as of today
>
> You had to define the 'named' symbol. Which means if you compiled a module using it, it wouldn't compile because named wouldn't be defined.

I have used a UDA called named before. Using @named in the final DIP would break code for no reason

On 11/09/2019 6:47 AM, Jonathan Marler wrote:
> Sorry in advance for the bikeshedding, but using the @ symbol just looks ugly to me. How about using 'public' instead of '@named'?
> 
>      void foo(@named bool log, @named bool goFast);
> Vs.
>      void foo(public bool log, public bool goFast);

I considered this quite some time ago.

It works for templates, but it does not work for functions.

I have also considered @property, which would also look ok for templates and functions but would be rather long.

Right now @named is the best of possible syntaxes given the semantics which have been proposed IMHO.

On 11/09/2019 9:10 AM, 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 

I stand by my question.
In your proposal there was no mention of template support.

You have since 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



However I disagree with your rationale.

"Although this supports reordering, the real reason for naming is so one can have a function with a longish list of parameters, each with a reasonable default, and the user need only supply the arguments that matter for his use case. This is much more flexible than the current method of putting all the defaults at the end of the parameter list, and defaulting one means all the rest get defaulted."

This is a known code smell with a known solution: refactoring.

I will posit that if you have code that has long parameters lists often, either you have a lot of technical debt or you are writing code that lends itself to introducing technical debt often.

For me at least, when I have long parameter lists, they typically involve math and are called in about one or two places at most and quite importantly all done within the same module. I do not believe that this warrants a language feature in of itself but I can be convinced that there are problems that lend itself to long parameter lists that are often solved.

Manu has a very interesting story related to this. Involving rewriting a code base for the purposes of refactoring of the data abstractions and ending up with faster code on platforms that it was expected to be much slower on.

On Tuesday, 10 September 2019 at 09:06:23 UTC, 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

I can't seem to find the rationale for the necessity of a parameter syntax? As a library writer, when would I annotate a parameter with `@named`? Does adding `@named` *require* naming the parameter? The DIP notes a new trait to find named vs unnamed parameters, but is that the *reason* for the new syntax or a handy side effect? Couldn't the regular UDA trait be used (or extended) to find `@named` or any other UDA for that matter?

If I assume there's a good reason for having this opt-in for parameters, wouldn't this then require a lot of churn for library writers, with diffs adding just `@named` to parameters and no other code changes?

"The primary aim of this proposal is to aid in readability and the implementation of tooling."

This primary aim can be achieved with less syntax and rules:
* No new parameter syntax
* Make argument names optional using the proposed `Identifier : ConditionalExpression` syntax, with a compiler error on identifier mismatch

Mentioning argument names at the call site improves readability and code robustness. This doesn't allow reordering, but also avoids any expectation of overloading based on parameter names.

Lio.

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

On 11/09/2019 7:01 PM, Walter Bright wrote:
>> 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 

Agreed.

> particular, struct literals and function calls cannot become a unified syntax, as they almost are today.)

Okay that I need to think about.

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.

On Wednesday, 11 September 2019 at 05:37:57 UTC, rikki cattermole wrote:
> This is a known code smell with a known solution: refactoring.
>
> I will posit that if you have code that has long parameters lists often, either you have a lot of technical debt or you are writing code that lends itself to introducing technical debt often.
>
> For me at least, when I have long parameter lists, they typically involve math and are called in about one or two places at most and quite importantly all done within the same module. I do not believe that this warrants a language feature in of itself but I can be convinced that there are problems that lend itself to long parameter lists that are often solved.

Long parameter lists usually aren't a code smell, and personal opinions and preferences are not enough to refute it. The alternative to long parameter lists is the Builder OOP pattern, which also usually isn't a code smell. Some records/objects just have many members and it doesn't make sense to split them up into smaller groups.

On 11/09/2019 8:16 PM, JN wrote:
> On Wednesday, 11 September 2019 at 05:37:57 UTC, rikki cattermole wrote:
>> This is a known code smell with a known solution: refactoring.
>>
>> I will posit that if you have code that has long parameters lists often, either you have a lot of technical debt or you are writing code that lends itself to introducing technical debt often.
>>
>> For me at least, when I have long parameter lists, they typically involve math and are called in about one or two places at most and quite importantly all done within the same module. I do not believe that this warrants a language feature in of itself but I can be convinced that there are problems that lend itself to long parameter lists that are often solved.
> 
> Long parameter lists usually aren't a code smell, and personal opinions and preferences are not enough to refute it. The alternative to long parameter lists is the Builder OOP pattern, which also usually isn't a code smell. Some records/objects just have many members and it doesn't make sense to split them up into smaller groups.

There are quite a few people who believe as I do that long parameter lists are a code smell or at the very least indicative that there probably is a problem with the data abstraction.

Maybe not convincing for part of a DIP (its not part of DIP 1020 after all), but I would hope that we can agree that this opinion is not limited to just a few people.



Chapter 24 of Code complete second edition: Reasons to refactor.

"Well-factored programs tend to have many small, well-defined routines that don't need large parameter lists. A long parameter list is a warning that the abstraction of the routine interface has not been well thought out."


The closest thing I can find in my writing solid code book for C is "Don't write multipurpose functions. Write separate functions to allow stronger argument validation." but I am not sure it applies (but it might do in some contexts).


https://stackoverflow.com/questions/439574/whats-the-best-way-to-refactor-a-method-that-has-too-many-6-parameters

http://www.tusharma.in/smells/LPL.html

https://medium.com/@KonfHub/refactoring-long-parameter-list-in-constructors-java-e9c9f2cb1fb