Inconsistent behaviour of attrset/list comparaison

[KAction]

Describe the bug

nix-repl> let u = { foo = 10; bar = (x: x); }; in u == u
true
nix-repl> let u = { foo = 10; bar = (x: x); }; in u.bar == u.bar
false
nix-repl> (x: x) == (x: x)
false
nix-repl> { foo = 10; bar = (x: x); } == { foo = 10; bar = (x: x); }
false
nix-repl> [(x: x)] == [(x: x)]
false
nix-repl> let u = [(x: x)]; in u == u
true
nix-repl> let u = [builtins.abort "foo"]; in u == u
true
-- Excuse me?! (EDIT: Nevermind, this is list of two elements, not appication).
nix-repl> [builtins.abort "foo"] == [builtins.abort "foo"]
false

Nix has inconsistent behavior when comparing lists and attrsets, more complicated than one described in
the manual.

Should we

• consider it a bug in nixcpp (and hence c++ should be fixed). I believe that this means undoing an useful performance optimization (eq?/equal?)
• consider it a bug in documentation, making this particular behavior an official language part, and forcing alternative implementations to do exactly the same.
• declare comparing lists/attrsets with function values an undefined behavior
• change both language and documentation to make functions non-comparable

From where I stand, I'd prefer option (3) and is willing to provide patches to nixpkgs, provided I get the blessing on the move direction.

Expected behavior

Not being able to break referential transparency with let bindings.

Checklist

• checked latest Nix manual ([source])
• checked [open bug issues and pull requests] for possible duplicates

[xokdvium]

Sadly this one is very complicated. A bit of what's going on here is described in https://nix.dev/manual/nix/2.34/language/operators.html#value-identity-optimization and there's also a great writeup here https://snix.dev/docs/reference/nix-language/value-pointer-equality/.

tldr; If you get rid of this nixpkgs breaks in very weird ways. It's a very common pain point for all the implementations, but the fact that nixpkgs relies on this is quite unfortunate. The only reasonable way forward here is to gradually introduce stricter lint flags to first fix nixpkgs and only then consider deprecating this/disabling pointer equality hack by default. For back-compat we probably couldn't get rid of this entirely though.

declare comparing lists/attrsets with function values an undefined behavior

It doesn't apply only to functions - self-referential structures can be compared due to pointer equality hack:

let a = { b = a; }; in a == a

[KAction]

And also found this: #3371

Also, what lint was you referring to? I think we need Nix interpreter support to identify when pointer-value-equality is applied.

[xokdvium]

Also, what lint was you referring to? I think we need it "Nix" interpreter help to identify when pointer-value-equality is applied.

Indeed, this gradual tightening would have to be done in the interpreter. One feasible approach would be to barf/warn on cases where pointer equality affects the result of value equality.

Is there any particular reason why functions don't get value-pointer-equality optimization?

Yeah, it's not that functions are special-cases in any way. It's just that pointer equality can only be observed when the Value doesn't get copied by-value as in the case above. https://snix.dev/docs/reference/nix-language/value-pointer-equality/ explains this pretty nicely.

Also:

-- Excuse me?!
nix-repl> [builtins.abort "foo"] == [builtins.abort "foo"]
false

Here it's a list of 2 elements - not a builtin function application.

[KAction]

-- Excuse me?!
nix-repl> [builtins.abort "foo"] == [builtins.abort "foo"]
false

Here it's a list of 2 elements - not a builtin function application.

My bad. You are correct, this is not relevant to the discussion. Is considered good practice to edit the original post for benefit for future readers, or will it cause more confusion?

[xokdvium]

Sure, you can edit and cross it out or something. I can mark the those comments as resolved too.