| 10 Nov 2025 |
 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 (rootile) | == 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 |
