On 19.05.20 04:35, Arine wrote:
> On Tuesday, 19 May 2020 at 01:07:38 UTC, Timon Gehr wrote:
>> On 19.05.20 02:05, Arine wrote:
>>> On Sunday, 17 May 2020 at 13:25:35 UTC, Timon Gehr wrote:
>>>> On 14.05.20 07:57, Walter Bright wrote:
>>>>>
>>>>> Besides, if you really don't want your users to use the parameter names,
>>>>>
>>>>>      int foo(int _dkfjjiufheuehgthu, long _yer_mother_was_a_hamster, double _I_did_not_read_the_documentation);
>>>>>
>>>>> and I bet they'll get the message.
>>>>
>>>> Or you can just use `int foo(int, long, double);`.
>>>
>>> Not that useful for open source code (the majority of D). Don't think I even know of or have used a single library that only provides .di files.
>>
>> int foo(int, long, double){
>>     return cast(int)(_param_0+_param_1+_param_2);
>> }
> 
> And that's better for readability? Both methods are equally as bad. That one may be worse because it is an undocumented "feature".
> 

I am not sure what your point is. Are you trying to argue that the suggestion is on the same level or worse than the originally proposed

int foo(int _dkfjjiufheuehgthu, long _yer_mother_was_a_hamster, double _I_did_not_read_the_documentation);

?

If that is not your point, I think we have nothing to discuss.

On 19.05.20 10:01, Timon Gehr wrote:
> On 19.05.20 04:35, Arine wrote:
>> On Tuesday, 19 May 2020 at 01:07:38 UTC, Timon Gehr wrote:
>>> On 19.05.20 02:05, Arine wrote:
>>>> On Sunday, 17 May 2020 at 13:25:35 UTC, Timon Gehr wrote:
>>>>> On 14.05.20 07:57, Walter Bright wrote:
>>>>>>
>>>>>> Besides, if you really don't want your users to use the parameter names,
>>>>>>
>>>>>>      int foo(int _dkfjjiufheuehgthu, long _yer_mother_was_a_hamster, double _I_did_not_read_the_documentation);
>>>>>>
>>>>>> and I bet they'll get the message.
>>>>>
>>>>> Or you can just use `int foo(int, long, double);`.
>>>>
>>>> Not that useful for open source code (the majority of D). Don't think I even know of or have used a single library that only provides .di files.
>>>
>>> int foo(int, long, double){
>>>     return cast(int)(_param_0+_param_1+_param_2);
>>> }
>>
>> And that's better for readability? Both methods are equally as bad. That one may be worse because it is an undocumented "feature".
>>
> 
> I am not sure what your point is. Are you trying to argue that the suggestion is on the same level or worse than the originally proposed
> 
> int foo(int _dkfjjiufheuehgthu, long _yer_mother_was_a_hamster, double _I_did_not_read_the_documentation);
> 
> ?
> 
> If that is not your point, I think we have nothing to discuss.

Actually, even if that is your point, I don't think we will reach an agreement, nor would it be important to do so.

On Tuesday, 19 May 2020 at 08:01:09 UTC, Timon Gehr wrote:
> On 19.05.20 04:35, Arine wrote:
>> On Tuesday, 19 May 2020 at 01:07:38 UTC, Timon Gehr wrote:
>>> On 19.05.20 02:05, Arine wrote:
>>>> On Sunday, 17 May 2020 at 13:25:35 UTC, Timon Gehr wrote:
>>>>> On 14.05.20 07:57, Walter Bright wrote:
>>>>>>
>>>>>> Besides, if you really don't want your users to use the parameter names,
>>>>>>
>>>>>>      int foo(int _dkfjjiufheuehgthu, long _yer_mother_was_a_hamster, double _I_did_not_read_the_documentation);
>>>>>>
>>>>>> and I bet they'll get the message.
>>>>>
>>>>> Or you can just use `int foo(int, long, double);`.
>>>>
>>>> Not that useful for open source code (the majority of D). Don't think I even know of or have used a single library that only provides .di files.
>>>
>>> int foo(int, long, double){
>>>     return cast(int)(_param_0+_param_1+_param_2);
>>> }
>> 
>> And that's better for readability? Both methods are equally as bad. That one may be worse because it is an undocumented "feature".
>> 
>
> I am not sure what your point is. Are you trying to argue that the suggestion is on the same level or worse than the originally proposed
>
> int foo(int _dkfjjiufheuehgthu, long _yer_mother_was_a_hamster, double _I_did_not_read_the_documentation);
>
> ?
>
> If that is not your point, I think we have nothing to discuss.

Both are equally as bad in terms of readability. One is worse because it uses an implementation detail that can change at any time.

On Wednesday, 20 May 2020 at 02:09:27 UTC, Arine wrote:
> On Tuesday, 19 May 2020 at 08:01:09 UTC, Timon Gehr wrote:
>> On 19.05.20 04:35, Arine wrote:
>>> On Tuesday, 19 May 2020 at 01:07:38 UTC, Timon Gehr wrote:
>>>> [...]
>>> 
>>> And that's better for readability? Both methods are equally as bad. That one may be worse because it is an undocumented "feature".
>>> 
>>
>> I am not sure what your point is. Are you trying to argue that the suggestion is on the same level or worse than the originally proposed
>>
>> int foo(int _dkfjjiufheuehgthu, long _yer_mother_was_a_hamster, double _I_did_not_read_the_documentation);
>>
>> ?
>>
>> If that is not your point, I think we have nothing to discuss.
>
> Both are equally as bad in terms of readability. One is worse because it uses an implementation detail that can change at any time.

So if the implementation detail is standardized, would you still object to this?

-Alex

On Wednesday, 20 May 2020 at 03:04:13 UTC, 12345swordy wrote:
> On Wednesday, 20 May 2020 at 02:09:27 UTC, Arine wrote:
>> On Tuesday, 19 May 2020 at 08:01:09 UTC, Timon Gehr wrote:
>>> On 19.05.20 04:35, Arine wrote:
>>>> On Tuesday, 19 May 2020 at 01:07:38 UTC, Timon Gehr wrote:
>>>>> [...]
>>>> 
>>>> And that's better for readability? Both methods are equally as bad. That one may be worse because it is an undocumented "feature".
>>>> 
>>>
>>> I am not sure what your point is. Are you trying to argue that the suggestion is on the same level or worse than the originally proposed
>>>
>>> int foo(int _dkfjjiufheuehgthu, long _yer_mother_was_a_hamster, double _I_did_not_read_the_documentation);
>>>
>>> ?
>>>
>>> If that is not your point, I think we have nothing to discuss.
>>
>> Both are equally as bad in terms of readability. One is worse because it uses an implementation detail that can change at any time.
>
> So if the implementation detail is standardized, would you still object to this?
>
> -Alex

Both methods are terrible. A pull request that used either method in phobos would be rightfully rejected today. It doesn't bode well when such a destructive practice is suggested by the creator of a language, and then they completely fall silent from the discussion. I hope he doesn't have have the same holier than though mindset as that other individual that clearly stated they don't care about having any kind of discussion on the subject at all. That's fine by me, it's clear as night and day to me. Practicality seems to be going out the door lately anyways.

On Wednesday, 20 May 2020 at 20:01:51 UTC, Arine wrote:
> On Wednesday, 20 May 2020 at 03:04:13 UTC, 12345swordy wrote:
>> On Wednesday, 20 May 2020 at 02:09:27 UTC, Arine wrote:
>>> On Tuesday, 19 May 2020 at 08:01:09 UTC, Timon Gehr wrote:
>>>> On 19.05.20 04:35, Arine wrote:
>>>>> On Tuesday, 19 May 2020 at 01:07:38 UTC, Timon Gehr wrote:
>>>>>> [...]
>>>>> 
>>>>> And that's better for readability? Both methods are equally as bad. That one may be worse because it is an undocumented "feature".
>>>>> 
>>>>
>>>> I am not sure what your point is. Are you trying to argue that the suggestion is on the same level or worse than the originally proposed
>>>>
>>>> int foo(int _dkfjjiufheuehgthu, long _yer_mother_was_a_hamster, double _I_did_not_read_the_documentation);
>>>>
>>>> ?
>>>>
>>>> If that is not your point, I think we have nothing to discuss.
>>>
>>> Both are equally as bad in terms of readability. One is worse because it uses an implementation detail that can change at any time.
>>
>> So if the implementation detail is standardized, would you still object to this?
>>
>> -Alex
>
> Both methods are terrible. A pull request that used either method in phobos would be rightfully rejected today. It doesn't bode well when such a destructive practice is suggested by the creator of a language, and then they completely fall silent from the discussion. I hope he doesn't have have the same holier than though mindset as that other individual that clearly stated they don't care about having any kind of discussion on the subject at all. That's fine by me, it's clear as night and day to me. Practicality seems to be going out the door lately anyways.


void fun(int,int)
_paramater[0] alias x;
_paramater[1] alias y;
}

I don't see anything "destructive" about this, given that we have the alias feature.

-Alex

On Wednesday, 20 May 2020 at 20:01:51 UTC, Arine wrote:
> On Wednesday, 20 May 2020 at 03:04:13 UTC, 12345swordy wrote:
>>
>> So if the implementation detail is standardized, would you still object to this?
>>
>> -Alex
>
> Both methods are terrible. A pull request that used either method in phobos would be rightfully rejected today. It doesn't bode well when such a destructive practice is suggested by the creator of a language, and then they completely fall silent from the discussion. I hope he doesn't have have the same holier than though mindset as that other individual that clearly stated they don't care about having any kind of discussion on the subject at all. That's fine by me, it's clear as night and day to me. Practicality seems to be going out the door lately anyways.

Here's a method that works using existing language features and doesn't rely on implementation details that aren't part of the language spec:

int foo(int, int)
{
    static if (is(typeof(__traits(parent, {})) params == __parameters)) {
        mixin("alias x = ", __traits(identifier, params[0..1]), ";");
        mixin("alias y = ", __traits(identifier, params[1..2]), ";");
    }
    return x + y;
}

unittest
{
    assert(foo(1, 2) == 3);
}

It's pretty ugly, but the ugliness is hidden entirely inside the function's implementation. And the whole static if block could be factored out into a mixin if you wanted to re-use it in multiple functions.

On Thursday, 21 May 2020 at 01:07:36 UTC, Paul Backus wrote:
> It's pretty ugly, but the ugliness is hidden entirely inside the function's implementation. And the whole static if block could be factored out into a mixin if you wanted to re-use it in multiple functions.

To wit:

mixin template parameterAliases(names...)
{
    static if (is(typeof(__traits(parent, {})) params == __parameters))
        static foreach (i, name; names)
            mixin("alias ", name, " = ", __traits(identifier, params[i..i+1]), ";");
}

int foo(int, int)
{
    mixin parameterAliases!("x", "y");
    return x + y;
}

On Thursday, 21 May 2020 at 00:35:21 UTC, 12345swordy wrote:
> On Wednesday, 20 May 2020 at 20:01:51 UTC, Arine wrote:
>> On Wednesday, 20 May 2020 at 03:04:13 UTC, 12345swordy wrote:
>>> On Wednesday, 20 May 2020 at 02:09:27 UTC, Arine wrote:
>>>> On Tuesday, 19 May 2020 at 08:01:09 UTC, Timon Gehr wrote:
>>>>> On 19.05.20 04:35, Arine wrote:
>>>>>> On Tuesday, 19 May 2020 at 01:07:38 UTC, Timon Gehr wrote:
>>>>>>> [...]
>>>>>> 
>>>>>> And that's better for readability? Both methods are equally as bad. That one may be worse because it is an undocumented "feature".
>>>>>> 
>>>>>
>>>>> I am not sure what your point is. Are you trying to argue that the suggestion is on the same level or worse than the originally proposed
>>>>>
>>>>> int foo(int _dkfjjiufheuehgthu, long _yer_mother_was_a_hamster, double _I_did_not_read_the_documentation);
>>>>>
>>>>> ?
>>>>>
>>>>> If that is not your point, I think we have nothing to discuss.
>>>>
>>>> Both are equally as bad in terms of readability. One is worse because it uses an implementation detail that can change at any time.
>>>
>>> So if the implementation detail is standardized, would you still object to this?
>>>
>>> -Alex
>>
>> Both methods are terrible. A pull request that used either method in phobos would be rightfully rejected today. It doesn't bode well when such a destructive practice is suggested by the creator of a language, and then they completely fall silent from the discussion. I hope he doesn't have have the same holier than though mindset as that other individual that clearly stated they don't care about having any kind of discussion on the subject at all. That's fine by me, it's clear as night and day to me. Practicality seems to be going out the door lately anyways.
>
>
> void fun(int,int)
> _paramater[0] alias x;
> _paramater[1] alias y;
> }
>
> I don't see anything "destructive" about this, given that we have the alias feature.
>
> -Alex

Editors that use the signature to get parameter names to help while you are writing code. It will have to be able to identify that pattern, and realistically you could define a parameter multiple times or not at the beginning of the function.

That also reminds me of the old C style function declarations, where the type and name were separated.

double foo( a , real )
    double *real;
    int a;
{
}

Not exactly the same, but it most definitely is a step backwards.

Then you also get into the problem of documentation for parameters. It is an overall net loss that just creates more problems of it's own. It'd make more sense to fix the problem here with named parameters, than to pass down the problem to something else.

On Wednesday, 13 May 2020 at 13:56:26 UTC, Steven Schveighoffer wrote:
> Hm... an interesting proposition, we could provide a way to disallow using names if the name starts with something like _:
>
> void foo(int _x)
> {
>    alias x = _x;
>    ...
> }
>
> foo(_x: 1); // Error
> foo(1); // OK
>
> It might be better than having to use .di files to prevent parameter-name based calling.
>
> -Steve

What about a @required (or a better name) that will force the user to use the named argument ?

---
void copy(string src, @required string dest) {}

copy(source: "myfile", "yourfile"); // Error: Missing named argument `dest:` before `"yourfile"`
copy("myfile", dest: "yourfile"); // Ok
---

Also, should named args, if used, always be spelt correctly ?
---
void anotherCopy(string src, @required destination: string dst) {}

void anotherCopy("file1", dest: "file2"): // Error: Named argument `dest:` must be spelt `destination:`
void anotherCopy("file1", destination: "file2"); // Ok
---