| 24 Feb 2026 |
 Sergei Zimmerman (xokdvium) | But that’s not exactly the thing we want for a well-defined lexical order. For now sorting on demand doesn’t seem to cost too much to be a blocker for fixing the impurity | 10:06:48 |
| Sergei Zimmerman (xokdvium) | * I mean, if somebody does the crazy and switches to a better representation that’d be great. FWIW there’s an immutable CHAMP implementation in immer that connor baker tried using for attrsets | 10:10:21 |
 piegames | In reply to @piegames:flausch.social
Any alternative solutions to this? How about always evaluating all values in comparisons, so that eval order does not matter because it's not as lazy? | 10:17:35 |
| piegames | Or how about treating values that throw as incomparable instead of propagating it up and beyond the comparison? | 10:18:22 |
| Sergei Zimmerman (xokdvium) | In reply to @piegames:flausch.social
Or how about treating values that throw as incomparable instead of propagating it up and beyond the comparison? It’s not really only about throw expressions though. Forcing all values would be a workable, though a more radical solution | 10:20:49 |
| piegames | Do we have numbers on how many comparisons even happen in Nixpkgs? My assumption would be that it's not that common and that most instances already fast forward because of the pointer comparison | 10:23:30 |
| Sergei Zimmerman (xokdvium) | Something like ~1M that doesn't shortcircuit and falls through to per-attr equality | 11:19:04 |
| Sergei Zimmerman (xokdvium) | For all drv-paths via -qaP --drv-path for x86_64-linux | 11:19:44 |
| Sergei Zimmerman (xokdvium) | That doesn't count derivation outPath equality and size mismatches of attrs | 11:21:33 |
 emily | the pointer comparison is hideously impure so not a good reason to not reduce existing impurity | 13:49:32 |
 K900 | Do we really want to say that flakes are hard frozen? | 13:49:47 |
| emily | the ordering also matches attrNames/attrValues | 13:49:49 |
| K900 | I feel like it's fine to pick some one-line patches that fix things | 13:50:03 |
| emily | so attrsets already have a canonical ordering | 13:50:04 |
| piegames | @k900:0upti.me that depends on whether that change may cause conflicts in the migration, I don't know the state of that CC @raitobezarius:matrix.org | 13:51:18 |
 raitobezarius | I am sorry I am failing to understand the conversation | 13:51:46 |
| raitobezarius | I read things on pointer comparisons from emily and things about flakes | 13:51:54 |
| raitobezarius | Can someone TLDR me? | 13:51:57 |
| raitobezarius | or repeat what they want from me | 13:52:00 |
| emily | i.e. you can implement an ordered-by-attrname == in Nix today (modulo pointer equality) | 13:52:13 |
| K900 | https://github.com/NixOS/nix/commit/3180671cabeb6a6010057770731e12761ed5666c cppnix broke flakes again | 13:52:16 |
| K900 | We could cherry-pick | 13:52:27 |
| K900 | Also the nix profile add thing from the other day | 13:52:37 |
| raitobezarius | man | 13:52:39 |
| K900 | I think it's fine to pick these small-ish changes that should merge cleanly into the migration | 13:53:01 |
| raitobezarius | Yes, but this change is non trivial from a libexpr perspective | 13:53:16 |
| raitobezarius | Now url Value have context strings? | 13:53:26 |
| K900 | Yeah that one might be too much | 13:53:34 |
| raitobezarius | I need to think | 13:53:47 |
| K900 | I was thinking about the nix profile add one more | 13:53:47 |
