May 16, 2020
On Friday, 15 May 2020 at 23:45:46 UTC, Arine wrote:
 Really if
> an implementer changes parameters around of the same type then that's them purposefully being malicious or they just don't give a ****.
>
You can make the same remark when it comes to changing parameter names.

-Alex

May 16, 2020
On 5/15/2020 12:56 PM, Jonathan M Davis wrote:
> I don't want to have yet more stuff added to a function's API which I then
> have to worry about whether I can change without breaking existing code. We
> already have enough such problems to worry about without adding more. And I
> don't want to have to deal with bikeshedding over parameter names like we
> too often have to deal with with function names and type names.

I almost never change a parameter name. I also can't see myself using named parameters very often. Nobody says anyone has to used them.

> From the
> perspective of someone writing libraries for others to use, I see named
> arguments as nothing but trouble. And as a user, I don't see them as adding
> any real benefit except in cases where functions have too many parameters
> anyway and probably should have been designed differently.

I'd like to have them just so we can get rid of that Flag!"Name".yes template abomination:

https://dlang.org/phobos/std_typecons.html#Flag

> Given that you're the one writing this DIP and that Atila has been in favor
> of named arguments for years, I expect that I'm going to be stuck dealing
> with named arguments in D at some point here,

Probably true.


> but I'm sure not happy about the idea.

Sorry about that. But I suspect you'll like it better than that awful `struct Yes`:

https://dlang.org/phobos/std_typecons.html#Yes
May 16, 2020
On Saturday, May 16, 2020 2:57:06 PM MDT Walter Bright via Digitalmars-d wrote:
> Sorry about that. But I suspect you'll like it better than that awful `struct Yes`:
>
> https://dlang.org/phobos/std_typecons.html#Yes

Marginally. Personally, I've always been of the opinion that just using true and false directly works well enough, but I seem to be in the minority around here in thinking that. Either way, while FlagName.yes is bad enough, Yes.flagName is completely backwards and ugly. So, it certainly won't hurt my feelings any if that goes away because of this.

- Jonathan M Davis



May 16, 2020
On 5/16/2020 2:14 PM, Jonathan M Davis wrote:
> Marginally. Personally, I've always been of the opinion that just using true
> and false directly works well enough, but I seem to be in the minority
> around here in thinking that. Either way, while FlagName.yes is bad enough,
> Yes.flagName is completely backwards and ugly. So, it certainly won't hurt
> my feelings any if that goes away because of this.

Glad to see we can agree on something!
May 17, 2020
On Saturday, 16 May 2020 at 13:30:34 UTC, matheus wrote:
> On Friday, 15 May 2020 at 23:45:46 UTC, Arine wrote:
>> On Wednesday, 13 May 2020 at 00:37:51 UTC, Walter Bright wrote:
> ...
>>> 2. what happens if the implementer changes the order of the parameters?
>>
>> See above. If they are the same type, then it probably isn't a meaningful change and can just be entirely avoided. Really if an implementer changes parameters around of the same type then that's them purposefully being malicious or they just don't give a shit.
>
> That's true.
>
> In fact who would do that? Who would change the order of parameters after a resource/feature is already exposed?
>
> For me this is pure suicide, and I wouldn't trust in this resource anymore.
>
> At least in some common and good libraries, APIs, SDKs or whatever I never saw this happen.
>
> Matheus.

Happened sometimes in Phobos, to put the range as a first parameter to a function, just to allow pipelining.

The solution was to add another function with the arranged parameters order.

So, sometime it happens...

May 17, 2020
On 2020-05-15 21:56, Jonathan M Davis wrote:

> I have _never_ used the struct initialization syntax, and I'm not sure that
> I've ever actually seen it used in any code that I've worked on. In my
> experience, it's also usually the case that structs aren't POD types and
> don't expose their members

I guess it depends on what kind of code you write. It's super useful when implementing or using web APIs that use JSON. When doing that I have one function per API endpoint, one struct for the request and one for the response. For those cases it's only POD structs with all members being public.

Just the other day I had to interface with the Datadog API. One of the API endpoints expects a JSON body with the following attributes:

struct Request
{
    static struct Time
    {
        string from;
        string timezone = "UTC";
        string to;
    }

    string index = "main";
    int limit;
    string query;
    string sort = "asc";
    string startAt;
    Time time;
}

The only attributes that are required are "query" and "time". With the struct initialization syntax it looks very nice:

const Request request = {
    query: "foobar",
    time: {
        from: "now-10s",
        to: "now"
    }
};

Without the above syntax I would need to either use the constructor syntax, which makes it very difficult to understand which attributes the values belong to. Or using regular field assignment, but then the variable cannot be const.

Request request; // cannot be const
request.query = "foobar";
request.time.from = "now-10s";
request.time.to = "now";

The above example could use the `with` statement to shorten the code a bit.

Then just serialize the struct to JSON and pass as the body of the HTTP request.

-- 
/Jacob Carlborg
May 17, 2020
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);`.
May 19, 2020
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.
May 19, 2020
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);
}
May 19, 2020
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".