Discussion Thread: DIP 1030--Named Arguments--Final Review

[WebFreak001]

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.