| 10 Nov 2025 |
 piegames | Glad we agree. I still need a vision how to do that for a language within the Nix ecosystem tbh | 08:19:45 |
 K900 | There's literally one place in nixpkgs where this is relevant | 08:19:47 |
| K900 | And it can be fixed with a treewide | 08:19:57 |
| K900 | Annoying as that may be | 08:20:02 |
| piegames | That would be possible but honestly feel weird | 08:20:12 |
| piegames | Which one? | 08:20:17 |
| K900 | Platform equality | 08:20:28 |
 Qyriad | In reply to @piegames:flausch.social
That would be possible but honestly feel weird it would make comparison trinary, ¯\_(ツ)_/¯ | 08:20:52 |
| piegames | How so? | 08:21:29 |
| K900 | Expr::eq(this, that) -> MsoTristate | 08:21:36 |
| K900 | When | 08:21:36 |
| Qyriad | you're probably right that it's better to not, though | 08:22:03 |
| K900 | (in case anyone isn't familiar, https://learn.microsoft.com/en-us/dotnet/api/microsoft.office.core.msotristate?view=office-pia) | 08:22:29 |
| piegames | What I dislike is that you have some data structure, it compares nicely, now you want to add a helper function that manipulates the data, suddenly your data has no equality anymore | 08:24:22 |
| Qyriad | yeah that's whatI don't like either | 08:57:14 |
| Qyriad | * yeah that's what I don't like either | 08:57:34 |
 Rutile (Commentator2.0) feel free to ping | == vs ===? /hj | 09:11:18 |
| Qyriad | ban == for sets entirely and require defining a __eq? /hj | 09:11:58 |
| piegames | So my take is that for most data structures ("types"), the code doesn't change between most instances. So it could be factored out of the comparison. Only attrs that actually need per-value functions to be different would be incomparable | 09:16:14 |
| piegames | Yknow, just the normal stuff from most every other language | 09:16:25 |
| K900 | I mean having a user defined __eq would be good for other reasons as well | 09:17:59 |
| K900 | But it's also a super hard compat break | 09:18:06 |
| Qyriad | I think something that is clear at the least is that Nixpkgs lib should have a lib.attrsets.equalsWithoutFunctions or something | 09:23:42 |
 Sergei Zimmerman (xokdvium) | It is there btw | 09:23:58 |
| K900 | There's lib.platforms.equals or something | 09:24:20 |
| K900 | But it will never be used consistently if the obvious thing is allowed | 09:24:30 |
| Sergei Zimmerman (xokdvium) | Also lib.systems.equals is horribly slow and inefficient | 09:25:04 |
| K900 | Imagine having sane platform definitions | 09:25:21 |
| K900 | tbh | 09:25:22 |
| Sergei Zimmerman (xokdvium) | I wanted to highlight that, yeah. There's no supporting the borked equality semantics with a more "optimized" object model. You either a) ditch support for old nix expressions b) suffer the lack of manoeuvrability in terms of the implementation. | 09:27:50 |
