NixOS Module System | 201 Members | |
| 46 Servers |
| Sender | Message | Time |
|---|---|---|
| 29 May 2026 | ||
*
Interesting. Is there a test I can run that covers that? By "merged" do you mean the Feels like that's related to the wider "addCheck is broken" issues exposed by v2 check+merge. | 20:20:11 | |
*
Interesting. Is there a test I can run that covers that? By "merged" do you mean the Feels like that's related to the wider "addCheck is broken" issues exposed by v2 check+merge. | 20:20:22 | |
| Yeah, I agree on hot-code. But on "normal" code, I tend to favor legibility over mirco-optimisation. Based on roberth's comment on your linked issue I'll keep your version, though:
| 20:24:11 | |
| oh, i should've sent the error - yeah that's the error that triggered
| 20:25:10 | |
| 30 May 2026 | ||
| 09:08:13 | ||
| 14:42:56 | ||
| 31 May 2026 | ||
| 15:42:01 | ||
| 15:45:02 | ||
| 22:00:31 | ||
| 22:00:39 | ||
| 5 Jun 2026 | ||
| 14:41:30 | ||
| is there any reason why this check would pass?
(this is a minimal example but the original type is also just an enum, and the merging doesn't throw any errors at all) i found this issue but i don't think that's related since it seems to be submodule- and oneOf-specific? | 14:46:14 | |
| * is there any reason why this check would pass?
(this is a minimal example but the original type is also just an enum, and the merging doesn't throw any errors at all) (also sorry if this isn't the place to ask noobish question like this, it seems like mostly technical discussion ;-;) | 14:53:12 | |
| * is there any reason why this check would pass?
(this is a minimal example but the original type is also just an enum, and the merging doesn't throw any errors at all) i found this issue but i don't think that's related since it seems to be submodule- and oneOf-specific? (also sorry if this isn't the place to ask noobish question like this, it seems like mostly technical discussion ;-;) | 14:54:10 | |
|
| 14:57:57 | |
| *
| 14:58:49 | |
| *
| 14:59:07 | |
| is it also supposed to do that during merging? this really feels like a bug, or at least a gigantic footgun if listOf throws away any further typecheck ^^; | 14:59:41 | |
| It delays it until use, rather than throw it away, no? | 15:00:07 | |
| personally in my case it just ignores it if i'm not mistaken. (i'll go check with my non-reduced example but i'd be surprised if it's different) | 15:00:49 | |
Hard to tell from skim-reading the merge function, but it looks like it is delegating checking & merging to the elemType and should surface type errors.It's possible that there's a v1/v2 checkAndMerge interface bug though, e.g. if the outer or inner type is using the v1 interface and the other part is using v2? | 15:02:11 | |
* Hard to tell from skim-reading the merge function, but it looks like it is delegating checking & merging to the elemType and should surface type errors.It's possible that there's a v1/v2 checkAndMerge interface bug though, e.g. if the outer or inner type is using the v1 interface and the other part is using v2? | 15:02:40 | |
check itself only doing isList pre-dates v2 checkAndMerge, though | 15:03:30 | |
hmmm ok in my real scenario i'm override a nonEmptyListOf's merge with mergeEqualOption, maybe that's why? | 15:04:28 | |
* hmmm ok in my real scenario i'm override a nonEmptyListOf's merge with mergeEqualOption (so that lists don't get merged), maybe that's why? | 15:04:42 | |
| ah yes that's why | 15:06:07 | |
If you're shadowing the merge attribute, then you're also removing any "delegate to elemType" logic unless your replacement merge itself delegates to the original merge. | 15:06:11 | |
ah, i assumed mergeEqualOption would look at the original type but now that i check it doesn't take any argument so it obviously can't know the original type | 15:07:00 | |
| well, i'll try to figure out how to make it work with the non-merging merge; thanks! | 15:07:39 | |
| For a similar example, I had this abomination when trying to extend a submodule's merge function earlier today. | 15:07:46 | |