Positional-only arguments

[fmeum]

I believe that https://peps.python.org/pep-0570, which describes very simple syntax for positional-only arguments, would be very useful to have in Starlark.

It does enable one to write clean and robust helper functions such as def format_rule_call(kind, /, **attrs) or def replace_fields(struct, /, **replacements) without having to worry about the edge case where a keyword argument kind or struct is passed.

This can currently be worked around to some extent by giving the positional arguments an odd name (e.g. __kind), but that's confusing, not guaranteed not to conflict and at odds with style guides.

[ndmitchell]

Note that the highly related PEP 3102 keyword-only arguments * syntax is already supported by Rust Starlark - https://github.com/facebookexperimental/starlark-rust/blob/38f480935dcfaf2a26a7c8e56fa2adc053b37b97/starlark/src/syntax/dialect.rs. It would seem to make sense that if Starlark were extended, it was extended with both.

[fmeum]

Keyword-only arguments are also supported in Bazel's implementation of Starlark and, from what I can tell, frequently used, especially in the Starlarkification efforts.

Citing @laurentlb from https://bazelbuild.slack.com/archives/CDCEKVCHY/p1678902971702729?thread_ts=1678902446.157669&cid=CDCEKVCHY

This can be discussed, but I don't think the syntax is very readable or intuitive, or well known by users in general. I think we're likely to push back on this unless there's a clear need.

I agree that the syntax isn't well known and perhaps also not intuitive. But I would consider the concept to be both well-known and intuitive. In more detail:

1. Many of the built-in methods, e.g. any or all, have positional-only arguments. Both from the point of view of consistency as well as mockability in tests, it seems like pure Starlark definitions of these methods should be able to have the same semantics.
2. Positional-only arguments would mostly be used by Starlark library or ruleset authors to make functions safe to use by end users without surprising edge cases. That is, the audience that would benefit the most from this feature (users of the functions) are also the ones that are the least likely to read the implementation and be confused by the /.
3. Since positional-only arguments only disallow unintended usages of functions and don't otherwise alter the behavior of the function, ignoring the / when mentally parsing a function definition is generally just fine.

[brandjon]

I rather like the idea of adding this feature to Starlark. We already have the concept of positional-only arguments for built-in methods defined in Bazel's Java code. And we've already run into problems where you have a **kwargs-accepting method that also takes in some fixed parameters that you don't want to name-clash with. (Ex: Imagine if we decided in the future to pass a ctx arg to symbolic macros, some of which happen to define an attribute named "ctx". Although even with this feature, the macro authors would still have to opt into changing their signature, or else undergo a mass migration.)

Laurent may have a point about surprising users with confusing syntax. So we'd have to balance that risk.

While I don't think this would necessarily be a difficult change to implement, it's not exactly trivial to review, given the subtleties of argument processing. And it would complicate the grammar. So this is blocked on 1) convincing evidence that it can carry its weight especially regarding not befuddling the average user, and 2) prioritization.