May 14, 2020
On Thursday, 14 May 2020 at 19:55:02 UTC, Steven Schveighoffer wrote:
> On 5/12/20 2:22 AM, Jonathan Marler wrote:
>> 
>> I'd really like to see the DIP include a proposal on parameter naming conventions for the standard libraries before we enable this.
>> 
>
> [snip]
>
>> 3. ...
>
> Another convention could be -- if a parameter starts with underscore, then the expectation is that you don't use named parameters with that argument. Such parameter names should always come first, and are subject to the parameter name changing without considering it to break code.
>
> If you use _xyz as a named parameter, and the name changes to _abc, that's your fault.
>
> Just an idea, in the event that we cannot find a good way to have the compiler prevent named parameter usage.
>
> -Steve

Yeah even if it's not enforced, a convention like that would be fine with me.  We just have to get everyone to agree on the convention....which is easier said than done :)
May 14, 2020
On Thursday, 14 May 2020 at 19:55:02 UTC, Steven Schveighoffer wrote:

> If you use _xyz as a named parameter, and the name changes to _abc, that's your fault.
>
> Just an idea, in the event that we cannot find a good way to have the compiler prevent named parameter usage.
>
> -Steve

Some people love Named Arguments. (They might overuse it)
Some people hate Named Arguments. (They might overlook good opportunities to use it)

If someone who hates named arguments creates a library, I don't really see the point of hir restricting the freedom of the developer that uses said library. The entire risk lies with the developer that loves named arguments, it should be upto that person to decide if the risk is worth it or not.

That said, as much as I love named arguments, I would never use an argument starting with underscore as it's simply too ugly, it's a very effektive deterrent, even without a convention... but with the added power of the convention the risk of using it would be minimal.

It's also possible that the opposite happens of what you all seem so afraid of, the library author decides to change the order of the arguments to facilitate UFCS but keeps the argument names unchanged, which saves the named argument user from breakage! I have made this kind of facilitate UFCS refactorings in my own codebase more often than changing argument names.

TL;DR
1) I think _ is effective
2) Using a di is also a good solution...
3) .. or having different submodules to keep backwards compatibility akin to namespace versioning in recent C++.

We have enough ways to handle this already, I'm totally with Walter on this one. Best DIP ever!

May 15, 2020
I totally think this DIP should go through, with no tedious opt-in impediments to anything. There is just no good reason to preemptively protect programmers at a language level from making a stylistic choice you don't like. If they want to use their named arguments in crazy ways (including reordering), just let them. People who find them helpful for certain situations can just use them distraction-free, and the people don't want to can just... not. The solution is incredibly clear.
May 15, 2020
On Friday, 15 May 2020 at 00:12:36 UTC, TheGag96 wrote:
> I totally think this DIP should go through, with no tedious opt-in impediments to anything. There is just no good reason to preemptively protect programmers at a language level from making a stylistic choice you don't like. If they want to use their named arguments in crazy ways (including reordering), just let them. People who find them helpful for certain situations can just use them distraction-free, and the people don't want to can just... not. The solution is incredibly clear.

I don't think the DIP should go through if there is no widespread consensus.
D already has a mechanism for verbose function arguments that is sufficient in cases in which you want to be more explicit about parameters:
https://dlang.org/phobos/std_typecons.html#.Flag
May 15, 2020
On Friday, 15 May 2020 at 00:12:36 UTC, TheGag96 wrote:
> I totally think this DIP should go through, with no tedious opt-in impediments to anything. There is just no good reason to preemptively protect programmers at a language level from making a stylistic choice you don't like. If they want to use their named arguments in crazy ways (including reordering), just let them. People who find them helpful for certain situations can just use them distraction-free, and the people don't want to can just... not. The solution is incredibly clear.

I agree, I think how it is the DIP is in a good state where it is clearly opt-in by the caller. For not changing parameter names, there needs to be some document actually specifying what is a breaking change and what isn't. Microsoft has a C# document specifying what is a breaking change. The renaming of parameters is considered a breaking change for Microsoft products there but that doesn't mean every library dev follows that rule for their own stuff.

Currently I think most D library devs already do stuff that could be considered even more breaking, because of traits and the whole ability to introspect. Named arguments are not so much of a problem because when a breaking change in names occurs, it's not a silent breakage but rather a compile time error for the caller.

For the ABI and like having explicitly forced named arguments which are also mangled, I could really much see some future DIP allowing something like `void copy(string src:, string dst)` which would force you to at least call it with `copy(src: "", "")` - I really want this change but first this DIP should go through as it is right now, I think it's a good base for something like that.
May 15, 2020
On Wednesday, May 13, 2020 1:55:20 PM MDT Jonathan Marler via Digitalmars-d wrote:
> On Wednesday, 13 May 2020 at 19:48:58 UTC, Panke wrote:
> > On Wednesday, 13 May 2020 at 19:44:32 UTC, Jonathan Marler
> >
> > wrote:
> >> I found a way:
> >>
> >> void copy(string, string destination)
> >> {
> >>
> >>     alias source = _param_0;
> >>
> >> }
> >>
> >> I didn't realize you could do this till now but this allows functions to "opt-out" of using named parameters.  We may want to consider using this pattern throughout phobos/druntime when we want want to prevent parameter names from being apart of the API.
> >
> > Makes the documentation worse though.
>
> If it makes the documentation worse then it means the parameter names were helpful to the API, in which case you wouldn't do this.  The "copy" function isn't a good example because the "source" and "destination" parameter names are actually helpful to include.

Just because having the parameter names in the documentation helps make the documentation clearer doesn't mean that it's desirable to actually have the parameter names be part of the API. Personally, I think that the documentation is much clearer and cleaner if the parameter names are in it, but I have zero interest in parameters names actually being part of the API where they then will cause code breakage if changed and risk causing even more bike-shedding arguments. I hate the whole idea of this DIP (and that of any other DIP that adds named arguments), but since Walter now seems to be on board wtih the idea, and I know that Atila has been for years, I expect that I'm out of luck, and I'm going to be stuck with some version of them in the language. If it weren't for how it affected the documentation, I almost certainly would stop naming any parameters on public functions and would use a "trick" like this one, though of course, that wouldn't fix it so that I wouldn't have to put up with named arguments in code just make it so that I wouldn't have to deal with how changing parameter names would break the code of anyone using any libraries I write.

- Jonathan M Davis



May 15, 2020
On Wednesday, May 13, 2020 11:19:21 PM MDT Walter Bright via Digitalmars-d wrote:
> On 5/13/2020 12:31 PM, Steven Schveighoffer wrote:
> > On 5/13/20 3:30 PM, Walter Bright wrote:
> >> In D, we do:
> >>     void copy(string, string destination);
> >
> > And how does the implementation of copy use that first parameter?
>
> ----- test.di -----
> void copy(string, string destination);
>
> ----- test.d ------
> void copy(string src, string destination)
> {
>      ...
> }

In general, .di files are an antipattern that just causes problems. They're necessary in some cases, but they don't work at all with templates (and of course, a lot of idiomatic D code is templated) and are problematic with stuff like auto return types. I'd be tempted to start using .di files everywhere to prevent having to deal with anyone using named arguments with any library I wrote, but it would make the code extremely painful to maintain in comparison and simply wouldn't work for a lot of code.

- Jonathan M Davis



May 15, 2020
On Tuesday, May 12, 2020 6:37:51 PM MDT Walter Bright via Digitalmars-d wrote:
> We already have named arguments in D since the very beginning - the struct initialization syntax.
>
> Not a single person has complained about breakage when implementers changed the names of the struct fields.

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, making it so that most structs wouldn't work with the struct initialization syntax anyway (and I'm that much less likely to have a POD struct in a library, because I don't want to have to deal with worrying about breakage caused by name changes). I think that it's quite safe to say that whatever impact struct initialization syntax has had is not at all on the same level that named arguments would have.

Personally, I wish that the struct initialization syntax didn't exist in D, but at least it seems to have relatively few people using it, whereas there are enough people who seem to like the idea of named arguments that I expect that once they're in, some people will start using them all over the place like they were writing python rather than D.

> This is similar to:
>
> 1. what happens if the implementer changes the types of the parameters?
>
> 2. what happens if the implementer changes the order of the parameters?
>
> Then user code breaks.
>
> If anything, this feature will motivate implementers to take some care to name the parameters appropriately.

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

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, but I'm sure not happy about the idea. It's a pythonism that IMHO just makes code worse - especially from the perspective of having to worry about code breakage and bikeshedding. And the fact that there are other things that you already have to worry about breaking when changing function signatures doesn't mean that adding yet more things that you have to worry about breaking isn't making things worse.

- Jonathan M Davis



May 15, 2020
On Wednesday, 13 May 2020 at 00:37:51 UTC, Walter Bright wrote:
> We already have named arguments in D since the very beginning - the struct initialization syntax.
>
> Not a single person has complained about breakage when implementers changed the names of the struct fields.


There's a simple workaround; it can even be deprecated!

struct A {
    int a;
}

// renamed a -> b

struct A {
    int b;
    deprecated alias a = b;
}

I feel like this was mentioned in the last thread too. I don't see the point in going around in circles if you aren't going to learn anything from it.

> This is similar to:
>
> 1. what happens if the implementer changes the types of the parameters?

It can be deprecated and overloaded at the same time.

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

> Then user code breaks.
>
> If anything, this feature will motivate implementers to take some care to name the parameters appropriately.

All of these have ways to have the new method and the old method existing in the codebase at the same time, with the old method being deprecated. It's not equivalent to the current DIPs suggested implementation.
May 16, 2020
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.