| 22 Mar 2026 |
 Lisanna | and the reason why c++ can never be made completely memory safe | 03:54:23 |
| Lisanna | everything in the std library uses cursed iterators | 03:54:34 |
|  @n0toose:ccc.ac left the room. | 12:39:36 |
|  KFears& 🏳️⚧️ (they/them) changed their display name from KFears 🏳️⚧️ (they/them) to KFears& 🏳️⚧️ (they/them). | 13:20:48 |
|  kungpaochicken joined the room. | 17:06:48 |
|  Enrico Cinti joined the room. | 22:39:19 |
| 23 Mar 2026 |
|  ShalokShalom changed their profile picture. | 02:05:20 |
|  nightuser changed their profile picture. | 11:30:46 |
 zoë (she/her) | is there any more feedback to give for Derivation with empty outputs gets an uncharacteristic error message (#1142)? and can anyone tell me if my comment on there is correct? it seems like a pretty trivial fix (maybe even candidate for E/easy, though i'm not sure how the team chooses which issues are suited for that) | 14:01:12 |
| zoë (she/her) | * is there any more feedback to give for Derivation with empty outputs gets an uncharacteristic error message (#1142) (eg with regards to whether it should be catchable or not, and if we should also change derivationStrict)? and can anyone tell me if my comment on there is correct? it seems like a pretty trivial fix (maybe even candidate for E/easy, though i'm not sure how the team chooses which issues are suited for that) | 14:02:02 |
| zoë (she/her) | * is there any more feedback to give for Derivation with empty outputs gets an uncharacteristic error message (#1142)? eg with regards to whether it should be catchable or not, and if we should also change derivationStrict
also can anyone tell me if my comment on there is correct? it seems like a pretty trivial fix (maybe even candidate for E/easy, though i'm not sure how the team chooses which issues are suited for that) | 14:02:23 |
 Qyriad | I think that should be pretty easy, yeah | 14:03:03 |
| Qyriad | Nothing in your comment strikes me as wrong, but we haven't looked at that part recently | 14:03:50 |
| zoë (she/her) | * is there any more feedback to give for Derivation with empty outputs gets an uncharacteristic error message (#1142)? eg with regards to whether it should be catchable or not, and if we should also change derivationStrict
also can anyone tell me if my comment on there is correct? it seems like a pretty trivial fix (maybe even candidate for E/easy to leave to some first-time contributors, though i'm not sure how the team chooses which issues are suited for that) | 14:04:28 |
 raitobezarius (DECT: 7248) | In general, I'd recommend doing the smallest amount of changes from increasing complexity | 21:34:09 |
| raitobezarius (DECT: 7248) | In this case, I'd recommend adding an error that has the same catch ability property as the one in drvStrict and from there we can pile up semantic changes with careful justification | 21:34:52 |
| raitobezarius (DECT: 7248) | If we restrict the changes to these atomic pieces, it's E/easy, I don't know if changing catch ability is not kind of Context/Maintainers because of some risky semantic changes we do not like in general | 21:35:48 |
| raitobezarius (DECT: 7248) | For the record, I am not sure I understand why we would make this error catchable, having an empty output list is always a fatal error, if your output list is conditional and dies when a platform is not supported or some data is unavailable, you should throw before the derivation thunk in its fully resolved form is resolved | 21:38:17 |
| raitobezarius (DECT: 7248) | So contrary to the opinions expressed, I'd keep a fatal error because it reports more useful information to the end users rather than waiting an access to the derivation to discover that the outputs list is empty for that specific instantiation of context | 21:39:10 |
| zoë (she/her) |
rather than waiting for an access to the derivation to discover that the outputs list is empty
i think i'm missing a step here, because i don't understand what the fatality of the error has to do with when it is reported. wouldn't a non-fatal and fatal error have the same laziness (assuming they're implemented by just changing derivation.nix)?
| 21:43:38 |
| zoë (she/her) | *
rather than waiting for an access to the derivation to discover that the outputs list is empty
i think i'm missing a step here, because i don't understand what the fatality of the error has to do with when it is reported. wouldn't a non-fatal and fatal error have the same laziness (assuming they're implemented by just changing derivation.nix)?
| 21:43:43 |
| zoë (she/her) | *
rather than waiting for an access to the derivation to discover that the outputs list is empty
i think i'm missing a step here, because i don't understand what the fatality of the error has to do with when it is reported. wouldn't a non-fatal and fatal error have the same laziness (assuming they're implemented by just changing derivation.nix)?
| 21:43:46 |
| zoë (she/her) | *
rather than waiting for an access to the derivation to discover that the outputs list is empty
i think i'm missing a step here, because i don't understand what the fatality of the error has to do with when it is reported. wouldn't a non-fatal and fatal error have the same laziness (assuming they're implemented by just changing derivation.nix)?
| 21:43:49 |
| raitobezarius (DECT: 7248) | A non fatal error will be silenced during large Nix evals or attribute names recursive enumeration by tryEval | 21:45:29 |
| raitobezarius (DECT: 7248) | A fatal error won't | 21:45:36 |
| zoë (she/her) | yeah but that's only if using tryEval, which imo is rarely seen in the average user's code | 21:46:15 |
| raitobezarius (DECT: 7248) | It's not a laziness issue more of a: there's a culture of using tryEval to perform certain CI operations where fatal or non fatal have different outcomes | 21:46:17 |
| zoë (she/her) | * yeah but that's only if using tryEval, which ime is rarely seen in the average user's code | 21:46:22 |
| zoë (she/her) | hmmm, i'll admit i don't have as much experience on the full ci side :/ | 21:46:46 |
| zoë (she/her) | * hmmm, i'll admit i don't have as much experience on the ci side :/ | 21:46:59 |
