Skip to content

Commit

Permalink
Discourage nested 'with' expressions
Browse files Browse the repository at this point in the history
  • Loading branch information
fogti committed Feb 4, 2025
1 parent 25c3f52 commit 7f22668
Showing 1 changed file with 98 additions and 0 deletions.
98 changes: 98 additions & 0 deletions rfcs/0120-no-nested-with.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,98 @@
---
feature: no-nested-with
start-date: 2021-01-11
author: Ellen Emilia Anna Zscheile (@fogti)
co-authors: @sternenseemann
shepherd-team: (names, to be nominated and accepted by RFC steering committee)
shepherd-leader: (name to be appointed by RFC steering committee)
related-issues: (will contain links to implementation PRs)
---

# Summary
[summary]: #summary

Disallow or discourage usage of multiple `with` expressions covering
the same expression / forbid nesting `with` expressions, even indirectly.
If infeasible in general (e.g. forbidding it in all nix expressions),
this can be limited to nixpkgs.

# Motivation
[motivation]: #motivation

It makes static analysis of nixpkgs easier, because as soon as `with`
expressions are nested, it becomes basically impossible to [statically
deduce where any free variable comes from] without implementing a
full-blown nix evaluator including lazy evaluation, which is difficult as
soon as `with` expressions and mutually recursive imports are involved
(e.g. as currently present in `nixpkgs/lib/systems/{inspect,parse}.nix`).

# Detailed design
[design]: #detailed-design

At least warn about any nested usage of `with` expressions,
at least when they get evaluated, possibly even when they get parsed.
After a grace period ("real time", probably a few months or years, not as in
"a timeout when interpreting" because that wouldn't make sense),
abort instead.

When the full approach (aborting instead of warning) is applied,
any reference to any free variable can be easily resolved
to the enclosing `with` expression "scope-include", and because
this `with` expression couldn't then be enclosed by another
one, even indirectly, no lookup ambiguity exists.

# Examples and Interactions
[examples-and-interactions]: #examples-and-interactions

```nix
pkgs: {
# allowed
a = with pkgs; patchelf;
# disallowed
b = with pkgs; with lib; patchelf;
# also disallowed
c = with pkgs; {
meta = with lib; {
license = with licenses; [ mit ];
};
};
}
```

# Drawbacks
[drawbacks]: #drawbacks

* Backward-incompatible, requires changing Nix code used "in the wild".

# Alternatives
[alternatives]: #alternatives

* Introduce a kind of `with-only` expression which allows bringing an attrset
into scope while simultaneously hiding the outer scope, such that all
inner free variables are either resolved via the given attrset, or
result in an error.
Similar to this is [RFC 110](https://github.com/NixOS/rfcs/pull/110),
which introduces an `inherit-as-list` construct which solves the primary
application of `with-only`, list specification in `meta` attributes of
nixpkgs derivatons.

* Completely ban the usage of `with` in nixpkgs;
seems unnecessarily excessive for this problem.

# Unresolved questions
[unresolved]: #unresolved-questions

Decide if this is enough.

e.g.
* Mutually recursive imports combined with `with` expressions also make static
analysis harder, because they require lazyness at the level of scope lookups,
which is difficult to implement corrently. e.g. [nix2js#2](https://github.com/YZITE/nix2js/issues/2)
* Check if any use case is too much negatively impacted by this.

# Future work
[future]: #future-work

* Static analyzers and transpilers for Nix

0 comments on commit 7f22668

Please sign in to comment.