DIP 1030--Named Arguments--Community Review Round 1 Discussion

[Paolo Invernizzi]

On Tuesday, 11 February 2020 at 14:45:30 UTC, 12345swordy wrote:
> On Tuesday, 11 February 2020 at 14:31:51 UTC, Paolo Invernizzi 
> wrote:
>> On Tuesday, 11 February 2020 at 14:22:48 UTC, 12345swordy 
>> wrote:
>>
>>> Then use cpp if you hate future code breakage that much.
>>
>> I don't go down that rabbit hole ... I've seen it too many 
>> times here.
>
> What rabbit hole are you talking about here!? The cpp committee 
> have religious like zeal when it comes to backwards 
> compatibility. You want d to have that mentality as well?
>
> -Alex

Probably I'm not able to explain myself clearly, so my fault ... 
let's try in this way.

- I'm not against changing D language specifications or Phobos 
with breaking changes, on the contrary, I'm an historical baker 
of doing it also with _major_ breaking changes, in times where 
talking about "breaking customer code in ANY way" was an heresy 
:-P

- Stated that, and coming back to named arguments, I prefer a 
language that encourage writing code that's difficult to break: 
virtual-by-default, for example, is against that principle. You 
should "explicitly" mark the methods that are parts of the API 
with virtual, turning encapsulation the default, and not the way 
round.

- The fact that fields _names_ are already part of the API is 
_not_ an excuse to add more stuff like that, with named 
parameters. The "he is doing wrong, so I can do wrong as well" is 
not an argumentation (and add to that "I've never had complains 
on that in other languages")

My reasoning is that, since months ago:

a) breaking user codebase, in any way, was BAD
b) so, a language feature that try to minimise (a) is GOOD
c) but now, we want to improve the language, so we can _sometime_ 
go against rule (a)
...
why rule (b) is not longer valid today? what is the _strong_ 
reason for turning D in a language _less_ robust to code 
refactories, encouraging a small and encapsulated API?

please, be sure to reply only if the first part of the post is 
clear enough ... :-)