Named only parameters.

[Y-Less]

Issue description:

So I've recently been using named parameters a lot more:

SomeFunction(7, .option = 9);

If you don't know, this is a way to only specify specific optional parameters instead of all of the preceding ones:

SomeFunction(7, 0, 5, 1, 9);

Even if you use _ as "default" it is still a bit unwieldy:

SomeFunction(7, _, _, _, 9);

Anyway, this isn't to talk about call sites, but declaration sites:

SomeFunction(parameter, first = 0, second = 5, third = 1, option = 7)
{
}

It would be nice to extend the . syntax to here as well to make parameters that can only be called via named parameter syntax:

SomeFunction(parameter, .first = 0, .second = 5, .third = 1, .option = 7)
{
}

This gives library writers way more flexibility in their optional arguments as they are no longer bound to a specific order, as people can no longer call the function with only positional arguments.

[Cheaterman]

This is a great idea IMO ; as discussed on Discord, there could also be a case for positional-only arguments, for functions where the argument names carry absolutely no information (eg add(a, b)).

[Y-Less]

As also discussed on github: My idea is that every keyword-only argument must include the . in their name, which would allow for mixing named-only and positional arguments in theory, but the semantics for that is very complex so I don't even want to think about it. For now I'd propose that once a . argument is seen all later ones must be the same:

Fine:

Func(arg1 = 5, .arg2 = 6, .arg3 = 7)
{
}

Error:

Func(arg1 = 5, .arg2 = 6, arg3 = 7)
{
}

This restriction could in theory be lifter later if a reasonable solution to this is found (but I'm not holding my breath).

[Daniel-Cortez]

@Y-Less If the user wants to make a pass-by-reference argument named-only, should the compiler expect the . first

Func(.&arg) {}

, or the &?

Func(&.arg) {}