| 11 Nov 2025 |
 raitobezarius | I feel like there's two directions from the current local optimum (?) we are, kicking function equality out of the language, figuring how far we are willing to go to repair lack of structural equality for complicated types like functions | 18:08:20 |
| raitobezarius | pennae are more in favor of kicking the thing out because there's no practical value to offer a real == for fns | 18:08:47 |
| raitobezarius | i was in favor of making == for functions complete, i.e. recursive ptr equality + semantic check if ptr equality fails | 18:09:07 |
| raitobezarius | but i sat down and looked how to do it and noped out | 18:09:17 |
 Sergei Zimmerman (xokdvium) | Quip: nix eval "github:nixos/nixpkgs?rev=a999c1cc0c9eb2095729d5aa03e0d8f7ed256780#pkgsCross.gnu64.bitwarden" --no-eval-cache. This wasn’t a regression and doesn’t evaluate under any nix impl. It was the case where nixpkgs machinery thought that it was doing this in cross and thus failed to eval | 18:09:42 |
| raitobezarius | aaaaaaaaah thanks | 18:09:54 |
| raitobezarius | well the other thing was a regression no? | 18:10:00 |
| raitobezarius | i know something that evals only on lix head now | 18:10:06 |
| 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 |
