[RFC 0058] Named Ellipses

[deliciouslytyped]

It should be possible to bind a name to ellipses in a function definition like { a, ...@extra }: null, and { a, extra@... }: null. This makes intuitive sense, and could remove the need for a lot of uses of removeAttrs that really just want to refer to the contents of ellipses.

Rendered

Edit:
Proposed discussion point:
Should scope of this be expanded to binding any function argument to new names - for consistency, even though that might be considered redundant? E.g.: a@{b@c, d@...}: null
Maybe it's preferable to get this simple RFC through first though.

[deliciouslytyped]

Note, I'm not really able to implement this by myself, so someone else will have to volunteer to implement it - or wait indefinite time for me to learn how.

[deliciouslytyped]

It has been proposed/pointed out to me over IRC that JavaScript uses ...somename.
I don't particularly have a preference - I didn't know there is a language that does this, but it initially felt somewhat aesthetically ugly, having no separator between whatever ... is, and the name. I consider my preference arbitrary though.

A more reasoned counterpoint however, would be desiring consistency with using @ like in a@{whatever}:?

[deliciouslytyped]

It may be relevant to this general discussion to explicitly point out that both a@{}: null and {}@a: null are valid. Not everyone knows this.

[7c6f434c]

I would say that Nix has a complicated enough syntax that increasing syntax complexity should be recognised as a drawback per se to be considered in comparison to the benefit. Every syntactical construct is a cost for third-party Nix-processing tooling, for example.

(I am not saying this drawback overweights the benefit here)

[deliciouslytyped]

I reluctantly agree and will add something later.

The lack of "user space" extensibility of Nix's syntax combined with that argument seems like a surefire way to tarpit any discussions about syntax "improvements", but I'm less experienced and still like more features. ;)

[7c6f434c]

Now that I think of it, the functionality (although not the syntax) could indeed be added as a library function (as a higher-order function).

(Or maybe I am wrong, there are a lot of details to check, I guess)

[7c6f434c]

Note that you want to consider pattern matching libraries, too, not just function arguments.

Some languages use notations that wouldn't fit well with the current use of ... in Nix: def f(a,b,*args): in Python, (lambda (a b &rest args) …) in Common Lisp.

[7c6f434c]

By the way, to avoid adding a new underspecified syntax construct in the language: is ({extra@...}: extra) {extra = 1;} a runtime error?

[asymmetric]

It would be useful to have an example of how people are currently using removeAttrs somehwere in the RFC, for comparison.

[deliciouslytyped]

Yeah that's what I meant. I'll add something when I have some spare brain for it, unless someone else wants to give it a shot.

[deliciouslytyped]

By the way, to avoid adding a new underspecified syntax construct in the language: is ({extra@...}: extra) {extra = 1;} a runtime error?

The question is whether extra = 1 should end up inside the ... right?

• If yes then it should be fine though it might be a bit confusing if one happens to have a name collision?
  Right now I'm leaning towards this option. Not because it seems easier, but because I feel it makes more sense.
• if no, you shouldn't be allowed to do that because - how do you say this... the name is being created by the interpreter - right?
  In which case I think we should fail at non-runtime if possible...

[7c6f434c]

> By the way, to avoid adding a new underspecified syntax construct in the language: is ***@***.***}: extra) {extra = 1;}` a runtime error? The question is whether `extra = 1` should end up inside the `...` right? - If yes then it should be fine though it might be a bit confusing if one happens to have a name collision? Right now I'm leaning towards this option.

Hm, given the current behaviour of `(args@{...}: args) { args = 1; }` it does sound reasonable that for `(args@{extra@...}: [extra args.extra]) { extra = 1; }` we get `[{ extra = 1; } 1]`; but this should probably be mentioned.

[deliciouslytyped]

Oh yeah, that's a nice and simple way to justify that.
(args@{...}: args) { whatever } == (args@{extra@...}: args) { whatever }
Edit: (question is are there any weird edge cases)

Naming ... should preserve the the semantics in the case of success.

[edolstra]

This RFC is now open for shepherd nominations. Any volunteers? I'm nominating myself :-) @7c6f434c Would you be willing to shepherd?

[7c6f434c]

I am close enough to being on the fence, so I accept the nomination.

I would also like to nominate @jwiegley as the lead author of a popular alternative Nix parser.

[deliciouslytyped]

I personally would still like to see this happen, but do not have the capacity to push for it until further notice.

[Mic92]

Has somebody time else to come up with examples?

[jtojnar]

Example: https://github.com/NixOS/nixpkgs/blob/67f489dae8ce99fb4a5418c87c5a91e327f3af11/nixos/tests/installed-tests/default.nix#L75-L81

[Mic92]

@7c6f434c could you organize a meeting for this one?

[7c6f434c]

Meeting, meeting… let's start by finding out if there is enough substance…

@deliciouslytyped are you interested in writing up more detailed motivation section for this RFC in any close future?

@jtojnar are you interested in maybe taking over / partially taking over this?

[jtojnar]

@7c6f434c Unfortunately, I do not have the bandwidth at the moment.

[7c6f434c]

@deliciouslytyped apparently my previous mention was just before you returned online.

[deliciouslytyped]

Sorry, still distracted.

[7c6f434c]

My opinion on meeting: it would be a cargo-cult as whatever is discussed will not realistically be implemented in predictable time.

My opinion on the current state: I am turning towards the idea to close with the decision like «defer». There is some level of positive interest in the community, and there is a question if enough consideration has been given to the costs and to the design trade-offs. Accepting this requires either more work on surveying the current Nixpkgs situation, potential mode of use, and consistency with other similar constructions in Nix and possibly in other languages; or maybe an implementation plan, which should both incentivise the justification work and allow to confirm the limited impact from varoius points of view.

Once someone has energy to either improve the justification part or implement it, the discussion can be continued.

[This is not yet a call for FCP, and probably not yet exactly the disposition I want to propose, just the likely direction]

[lheckemann]

Shall we close this until we have some developments here?

[7c6f434c]

Almost a month later, I formally motion for FCP with disposition to close until interest in further work is present. We have seen some interest in this feature, but to commit to a design as an RFC decision either more surveying/documentation work (and discussion of specific trade-offs based on more data) or some prototyping would be needed.

Continuation of discussion might be a reopening or a new RFC.

@edolstra @jD91mZM2

[edolstra]

@7c6f434c I agree, let's FCP this for now. (Maybe @jD91mZM2 wants to reply as well.)

[jD91mZM2]

Sure, I agree, let's FCP it. It's a convenient feature, but not something we have seen massive reason to push for yet.

[7c6f434c]

Thanks.

Final Comment Period starts on this RFC with a disposition to close as «deferred». The proposal got positive feedback, but more work is needed for final commitment to accept details of the design.

Thanks to everyone who contributed to the discussion, hopefully the record will be useful at some future point when we revisit this topic.

[nixos-discourse]

This pull request has been mentioned on NixOS Discourse. There might be relevant details there:

https://discourse.nixos.org/t/rfc-0058-fcp-named-ellipses-with-disposition-to-defer/9603/1

[edolstra]

Thanks, I've closed with label "status: deferred".

[nixos-discourse]

This pull request has been mentioned on NixOS Discourse. There might be relevant details there:

https://discourse.nixos.org/t/is-it-possible-for-us-to-remove-builtins-functionargs/51960/2