| 11 Nov 2025 |
 Sergei Zimmerman (xokdvium) | In reply to @raitobezarius:matrix.org
well the other thing was a regression no? Yeah, some old nixos config from flake-regressions | 18:10:40 |
 raitobezarius | yeah, ok it was indeed from flake-reg | 18:11:32 |
| raitobezarius | (i imagined that and therefore i did yesterday: https://git.lix.systems/raito/flake-regressions) | 18:11:48 |
| raitobezarius | This is going into the pennae's direction from my understanding | 18:12:31 |
| raitobezarius | People can decide to have a cmp fn function they use in their local context | 18:12:44 |
 KFears (burnt out) | In reply to @raitobezarius:matrix.org
This is going into the pennae's direction from my understanding Yeah | 18:14:11 |
 Taeer Bar-Yam |
no practical value to offer a real == for fns
except backward compatibility, right?
| 18:29:12 |
 Winter | @raitobezarius do you remember the context to https://git.lix.systems/lix-project/nixos-module/commit/a50986cfc71dfd60acaf55d31d1e3e05e9bdde6d ? | 18:49:04 |
| Winter | working on a semi-related change for nixpkgs and want to know if making nixos-option use config.nix.package would be bad/cause a bunch of rebuilds tm | 18:49:29 |
| raitobezarius | i think nixos-option code is deeply integrated with C++ API | 18:50:02 |
| raitobezarius | nix 2.18 seemed a reasonable pin at that time | 18:50:09 |
| raitobezarius | lix is not because of nixos-option developers are not striving for lix/nix C++ API compat | 18:50:29 |
| raitobezarius | * lix is not because of nixos-option developers are not striving for lix/nix C++ API compat (afaik) | 18:50:34 |
| raitobezarius | not even that, right? | 18:50:53 |
| raitobezarius | in the current semantics, people can manipulate Nix to observe very specific details of the impl | 18:51:04 |
| raitobezarius | if the same people change the interpreter innards and cause these observations to go wrong | 18:51:25 |
| raitobezarius | what are the eval stability expectations we should offer here? | 18:51:35 |
| raitobezarius | a real == for fns will make more things true, hence, if you rely on false-y values somewhere in your magic code, then we will destroy the stability as well here | 18:52:01 |
| raitobezarius | the best thing i can muster/do is to take real world examples and analyze how much we are breaking vs. keeping working | 18:52:15 |
| Winter | no it's a shell script now | 18:52:21 |
| raitobezarius | i'm happy to do crater-style runs for that | 18:52:22 |
| Winter | so i guess that was when it was in C++ | 18:52:29 |
| raitobezarius | aaaaaaaaaaaaaaaaaaaaaah | 18:52:30 |
| Winter | for god knows what reason | 18:52:32 |
| Winter | lol | 18:52:32 |
| Winter | ok thanks | 18:52:35 |
| raitobezarius | :D | 18:52:39 |
| Winter | i'll submit some PRs then ^^ | 18:52:41 |
| raitobezarius | thanks! | 18:52:45 |
| Taeer Bar-Yam | yeah, checking real-world cases is essential, but there is also something more pernicious about relying on false-y values than true-y values. if we throw out any notion of function equality, we break code that more reasonably relies on true-y values too. | 19:05:07 |
