Add support for PEP 614-style decorators

[sleiner-v]

These allow us to write patterns where functions definitions are passed through other functions more concisely, e.g.:

def func():
    ...
func = register(func)

is equivalent to

@register
def func():
    ...

Depending on the API design, I find this to be highly useful for avoiding boilerplate. It is not part of the official Starlark specification though, and an inquiry from a few years ago suggests it is unlikely to land, see 1.

[meta-cla]

Hi @sleiner-v!

Thank you for your pull request and welcome to our community.

Action Required

In order to merge any pull request (code, docs, etc.), we require contributors to sign our Contributor License Agreement, and we don't seem to have one on file for you.

Process

In order for us to review and merge your suggested changes, please sign at https://code.facebook.com/cla. If you are contributing on behalf of someone else (eg your employer), the individual CLA may not be sufficient and your employer may need to sign the corporate CLA.

Once the CLA is signed, our tooling will perform checks and validations. Afterwards, the pull request will be tagged with CLA signed. The tagging process may take up to 1 hour after signing. Please give it that time before contacting us about it.

If you have received this in error or have any questions, please contact us at cla@meta.com. Thanks!

[meta-codesync]

@facebook-github-bot has imported this pull request. If you are a Meta employee, you can view this in D105672148. (Because this pull request was imported automatically, there will not be any future comments.)

[JakobDegen]

Hey, thanks for the PR! While we appreciate why you might want this, I discussed this a bit with @ndmitchell , we think this extension is probably not one that we want to take.

We don't really have a policy for how we decide whether to accept an extension or not, but there's a couple things that I can identify here that speak against it.

• This is of limited value; I assume you can live without it.
• It's been explicitly rejected upstream for violating starlark design goals
• It has relatively large surface area for coming into conflict with other changes to the language, either directly (syntax ambiguity) or in terms of design/spirit

So I'll close this for now; thanks anyway!

[sleiner-v]

Hi @JakobDegen,

thanks for the clear feedback and for taking the time to look this up 👍

For the record, regarding your points:

• This is of limited value; I assume you can live without it.

For the shape of API that I am working, I deem this to be very valuable. But that API is probably different than most Starlark APIs (and certainly different than Buck2 or Bazel). So, I can see why you wouldn't want to land the feature upstream, I will keep this in my patched tree of starlark-rust.

• It's been explicitly rejected upstream for violating starlark design goals

Yup, yet another reason why it makes sense to not add this here.

• It has relatively large surface area for coming into conflict with other changes to the language, either directly (syntax ambiguity) or in terms of design/spirit.

Regarding syntax ambiguity at least, I am not concerned: Since the patch mirrors Python syntax, which the Starlark syntax is a strict subset of, I considern the syntax to be proven in use, even in conjunction with more syntax elements than Starlark currently has.

Regarding the spirit of the Starlark spec, I think the rejection from the spec says it all 😅