| 18 Jan 2026 |
|  losvedar joined the room. | 17:37:54 |
|  isabel changed their profile picture. | 20:43:31 |
| 19 Jan 2026 |
 niksnut | looks good to me in principle | 10:01:39 |
 raboof | is it expected that // is not lazy? i.e. it evaluates the LHS even if the RHS holds the thing I'm taking from it? | 14:26:57 |
| raboof | * is it expected that // is not lazy? i.e. it evaluates the left parameter even if the right parameter holds the thing I'm taking from it? | 14:27:44 |
 Alyssa Ross | nix-repl> ({ foo = throw "oh no"; } // { foo = 1; }).foo
1
| 14:28:09 |
| Alyssa Ross | looks lazy to me? | 14:28:13 |
| raboof | nix-repl> ((throw "oh no") // { foo = "foo"; }).foo
error: oh no
| 14:31:30 |
 ma27 | attr-names are generally not lazy in Nix, hence the throw is being evaluated. | 14:32:02 |
| raboof | I read // as a function (in infix notation) with two parameters, perhaps that's not how this works? | 14:32:41 |
| raboof | right, so // creates its set of attr-names at first access. that makes some sense I guess. | 14:40:42 |
 Sergei Zimmerman (xokdvium) | In reply to @raboof:matrix.org
is it expected that // is not lazy? i.e. it evaluates the left parameter even if the right parameter holds the thing I'm taking from it? Yes, attribute names are evaluated eagerly in part due to how attrsets are stored internally | 14:42:23 |
 Mic92 | Also because they have to be lexical sorted, no? | 14:56:23 |
 Robert Hensing (roberth) | It's the simple thing to do, and simple is fast, usually. Not being simple is what stalled https://github.com/NixOS/nix/pull/4154 | 14:57:32 |
| Robert Hensing (roberth) | Could be revisited, but it does change the language semantics so that's tricky, and hard to backtrack away from in the future | 14:58:10 |
| Mic92 | Yeah, feels hard to make this bug-compatible with the current behaviour. | 14:58:51 |
| Mic92 | One could have an infinite attrset that would work with new nix, but not with old nix. | 14:59:24 |
| Mic92 | Also that would be less likely the biggest issue | 14:59:51 |
| Robert Hensing (roberth) | It'd be subtler current errors that would be the problem, mostly infinite recursions that would be lifted in the new Nix language | 15:01:10 |
| Robert Hensing (roberth) | (or at least those would be the ones people would complain to me about :) ) | 15:01:50 |
 Taeer Bar-Yam | Generally turning errors into correct behaviour is the least bad way to break compatibility, right? Though it causes more problems now that we have other forks of nix | 15:07:26 |
| raboof | yeah I wasn't saying we should change this, just calibrating my expectations ;) - but nice to see more people have been pondering (and even hacking on) this ;) | 15:07:34 |
| Robert Hensing (roberth) | no, raboof, you are in the rabbit hole with us now! | 15:08:04 |
| Robert Hensing (roberth) | I agree it's a good kind of change, but the second order effects are real. E.g. you upgrade, you use it, I don't, it fails for me, I complain, we lose | 15:09:02 |
| Robert Hensing (roberth) | not to say we can't get over that. It's still an improvement, but is it the right thing to do now? | 15:10:05 |
| Robert Hensing (roberth) | I'd want to know the long term impact on evaluator performance including opportunities missed. tricky. | 15:10:47 |
| Robert Hensing (roberth) | maybe it's a cognitohazard and we should just ignore it for another year | 15:12:57 |
| raboof | yeah, performance-wise it's hard to predict the trade-off between the benefit of not needing to evaluate the first parameter vs the cost of delaying when it's needed after all - AFAICT infinisil's work seems to suggest it's not a huge benefit (if at all). | 15:13:54 |
| Taeer Bar-Yam | Also would this change solve anything for anyone or improve anything? I don’t think I’ve ever run into a situation that needed it, personally | 15:13:58 |
| Robert Hensing (roberth) | It could solve a portion of infinite recursions that necessitate lazyAttrsOf instead of attrsOf in module system use. Actually it might make that use case worse because definition merge order is deterministic but arbitrary in the module system. | 15:16:08 |
