> if it means the same object/array spread syntax can be used everywhere for the same effect
It cannot. Because, as you yourself said it: the function must know how to deal with object-as-parameters.
> relating on composition of core syntax features over introducing new syntax
This doesn't work for named arguments. They either exist in a language, and you can use them everywhere, or they don't, and you're left with inconsistently implemented workarounds.
It can - you pass objects to functions declared with named parameters, and you pass lists to functions declared with positional parameters. It is true that the function must be written one way one or the other a. priori (it could theoretically detect, but that’s not ideal).
And what I’m saying is that if they don’t exist in a language and you can instead using other more core things in the language to implement them rather than adding new syntax (complexity) to the language itself, that’s (in my opinion) a better language and the one I’d rather work in.
> It can - you pass objects to functions declared with named parameters, and you pass lists to functions declared with positional parameters.
Once again: these are workarounds and there are no "functions declared with named parameters" in Javascript. There are functions that accept objects as a parameter, and they employ additional code to work with those objects.
Example:
function add(x, y) {}
No matter how much you try, you cannot "use the core thing in the language" to make this function accept this
add(x = 1, y = 2)
// or
add({x: 1, y: 2})
without writing additional code inside the function itself.
So if a library gives you `function add(x, y)`, that's what you're stuck with, forever. You cannot pretend that named arguments can be solved by "javascript's core language". It cannot.
It’s really not as complicated as you’re making it out to be. If I’m making a function that has potentially confusing parameters, I make it accept an object. This forces named parameters, and it does so only using core language features.
Yes, there’s no dedicated syntax to allow people to name parameters that weren’t intended to be named. So what?
> It’s really not as complicated as you’re making it out to be.
Of course it's not complicated, it's as simple as I showed.
> If I’m making a function that has potentially confusing parameters, I make it accept an object.
It doesn't really matter what you, a single developer, do, does it?
If I have to work with a third-party library that has "confusing parameters", please enlighten me how I can make its functions "accept an object to force named parameters"?
> there’s no dedicated syntax to allow people to name parameters that weren’t intended to be named. So what?
I've clearly shown what in at least three messages.
It cannot. Because, as you yourself said it: the function must know how to deal with object-as-parameters.
> relating on composition of core syntax features over introducing new syntax
This doesn't work for named arguments. They either exist in a language, and you can use them everywhere, or they don't, and you're left with inconsistently implemented workarounds.