[RFC 0120] Discourage nested with expressions

[fogti]

Rendered

This has come up while trying to implement alternative interpreters/evaluators for the Nix language, and similar tools which need to perform static analysis on Nix expressions.

This idea is a compromise. The original idea was to forbid with expressions completely, which proved to be undesirable and impratical. A related idea was the introduction of a with-only expression, but it (1) wouldn't completely solve the problem and (2) introduce another keyword with no apparent immediate benefit.

This issue was discussed quite a few times on various channels, and this is an attempt to move closer to a solution.

cc @sternenseemann

[L-as]

Related: #110

[gytis-ivaskevicius]

For the record let me explain what @L-as means by noting inherit-as-list RFC. Assuming this RFC gets implemented - there is no need for with-only expressions due to syntaxes as such:

# Basic usecase:
meta = {
  inherit homepage; # inherit in attribute set
  license = with licenses; [ inherit (lib.licenses) mit  ]; # inherit in list
}

# Not so obvious syntax
let inherit (lib) mapAttrs filterAttrs; in {
  a = mapAttrs (a: b: xyz) abc;
  b = filterAttrs (it: xyz) abc;
}

[lheckemann]

This RFC is now again open for nominations :)

[kevincox]

This RFC has not gotten any nominations which appears to show lack of interest from the community. In order to drive this RFC forward I recommend trying to help find shepherds by reaching out to people you know and posting in discourse or Matrix.

If no shepherds can be found we will convert this RFC to draft to be on hold until we can find enough interested participants.

[tomberek]

To re-iterate the previous comment, this RFC will require some shepherds in the next two weeks otherwise will be turned into a draft awaiting further interest.

[fogti]

A simpler alternative to this would be to "just" forbid mutual imports combined with with-expressions, because these prevent the import structure from forming a DAG, and have no unambiguous translation to explicit fixed points (lib in nixpkgs is an unambiguous and explicit fix point); which is the case which triggered the problem in the first place, because "no unambiguous translation" means that interpreting nix files separately or on a one-by-one basis is hard, because the scope is temporarily ambiguous...

[AndersonTorres]

Related:
NixOS/nixpkgs#294383
NixOS/nixpkgs#292468 (comment)
https://github.com/NixOS/nixpkgs/pull/298316/files