| 9 Nov 2025 |
 aloisw | Ah fuck I forgot to change f back to a function. | 18:10:03 |
| aloisw | Confirmed this is the breaking change. | 18:12:25 |
 raitobezarius | https://gerrit.lix.systems/c/lix/+/4556 | 18:16:23 |
| raitobezarius | not totally | 18:16:49 |
| raitobezarius | we looked hard and we were not able to disprove our theory that we were enabling more correctness | 18:17:03 |
| raitobezarius | like we ran evaluation regression testing and we had no failure but new successes | 18:17:22 |
| raitobezarius | after looking hard at the new success, we were unable to say "ah it's wrong", but more like: ah it's possibly a fun eq ptr bug | 18:17:44 |
| raitobezarius | put in another way, breaking bug to bug compatibility: yes, by having a behavior that agrees on successes: yes, new failures: not an intended objective | 18:19:11 |
| raitobezarius | * put in another way, breaking bug to bug compatibility: yes, by having a behavior that agrees on existing successes: yes, new failures: not an intended objective | 18:19:21 |
 Sergei Zimmerman (xokdvium) | In reply to @raitobezarius:matrix.org
put in another way, breaking bug to bug compatibility: yes, by having a behavior that agrees on existing successes: yes, new failures: not an intended objective Yeah, that’s why I meant by compat. | 18:19:38 |
| raitobezarius | in general, i'd like to kick pointer inequality out of the lang | 18:20:18 |
| Sergei Zimmerman (xokdvium) | Seems like it would be beneficial to run a regression on older nixpkgs as well, since apparently it suffers much more from pointer equality footguns. | 18:20:18 |
| raitobezarius | yep | 18:20:25 |
| raitobezarius | we should definitely do that | 18:20:30 |
| Sergei Zimmerman (xokdvium) | In reply to @raitobezarius:matrix.org
in general, i'd like to kick pointer inequality out of the lang Indeed. I doubt anybody wants to keep it around, but it’s not like frontend semantics where one can just copy the parser code. If one wants to keep the ability to eval legacy nix code then it doesn’t seem possible to get the object model benefits (like single-pointer values) without also keeping bug-for-bug compat | 18:24:26 |
 Taeer Bar-Yam | I've been talking with Sergei Zimmerman (xokdvium) about this issue over the last couple weeks, and one idea that I had was to go further in the opposite direction. Rather than running pointer equality on functions (or perhaps in addition), have functions compare equal if they comprise the same Expr and Env.
Also be aware I haven't looked at Lix code only CppNix, so maybe this doesn't make sense given how they've diverged.
| 18:25:21 |
| Sergei Zimmerman (xokdvium) | In reply to @raitobezarius:matrix.org
in general, i'd like to kick pointer inequality out of the lang * Indeed. I doubt anybody wants to keep it around, but it’s not like frontend semantics where one can just copy the parser code. If one wants to keep the ability to eval legacy nix code then it doesn’t seem possible to get the object model benefits (like single-pointer values) without also ~~keeping~~ yeeting bug-for-bug compat | 18:26:18 |
| Taeer Bar-Yam | My thinking is that people are much more likely to depend on the behaviour "these equal functions compare equal" than "these equal functions compare non-equal". So if you're going to break backward-compatibility in some direction, it should probably be in the direction of allowing more functions to compare equal when they are, in fact, equal as functions. | 18:27:14 |
| raitobezarius | Indeed, it was an opportunistic naive attempt we could not disprove (until you provided the example and thank you!) its soundness | 18:27:49 |
| raitobezarius | The bar for changing that is going to be much higher now | 18:27:56 |
| Sergei Zimmerman (xokdvium) | Tvix folks have great insights into the pointer equality semantics. I did get a lot of grumbling about pointer equality semantics from glittershark and edef | 18:30:27 |
| * raitobezarius nods | 18:31:02 |
| raitobezarius | (i also listened more than once to edef about ptr equalities) | 18:31:14 |
| aloisw | Well the pointer equality only matters for types that use an auxiliary block, so I assume copying that in the places where the value was previously copied would work? | 18:40:11 |
| 10 Nov 2025 |
|  @adis:blad.is left the room. | 04:58:06 |
 piegames | The would probably not mesh well with future performance optimisations | 08:07:14 |
| piegames | mixing code with data was a mistake | 08:17:16 |
 K900 | Honestly IMO the only way to do function equality at this point is to hard ban it | 08:17:52 |
| K900 | Because any attempt to fix the semantics will lead to code that evaluates subtly differently wrong on new and old semantics | 08:18:25 |
| piegames | Yes but once you ban it you want to move off all functions off your data structures to retain the ability to compare your data | 08:18:42 |
