[jakear]

But there’s no expanding happening here? So why take a token that’s immediately recognizable as either “expanding” or “muliplying-ish” and extend it to mean “or enforcing named parameters and not expanding”?

> cluttered and ugly

I won’t argue with you about visuals because I don’t think they’re all that important. But, I think it’s undeniable that reusing the same syntactic concepts across different semantic use cases is quite a lot more logically clean & beautiful than introducing new syntax that other HN commenters with past python experience can’t even understand. If someone sees the JS named parameter syntax at a declaration and has any JS experience, they’ll almost certainly figure out what to do - if someone sees the asterisk, even with Python experience, they’ll think “what the heck is this asterisk?” And again, the other commenters on this thread are clear evidence that this is indeed as unintuitive as I describe.

[masklinn]

> But there’s no expanding happening here?

There's a collection of 0 arguments. the "∗" was introduced specifically as a shortcut for:

    def foo(a, *ignore, b):
        if ignore:
            raise TypeError

forgoing the name simply signals to the language that it should collect nothing.

It's a logical extension of the assumption that anything which follows `∗arg` is a keyword-only parameter.

[jessedhillon]

    *args

creates a catch-all variadic function parameter called `args` which matches all positional parameters not heretofore assigned

    *

(same operator, without a name following) indicates that no more positional parameters may be matched after this point

They are close enough cognitively to warrant reuse IMO.