<ekleog>
ugh. so real code in nixpkgs (or not far) even depends on this behaviour. so even patching nix won't save me :(
<infinisil>
(And see the comment on the argument too)
<infinisil>
(Well this code is not in nixpkgs yet)
<ekleog>
the world makes no sense :(
<ekleog>
(sorry I'm just sulking)
<ekleog>
that makes typechecking arguments to functions uselessly hard :(
<infinisil>
Hmm
<infinisil>
Another reason Nix isn't made for types :)
<ekleog>
heh
<ekleog>
another reason why nix makes it uselessly hard to add a decent typing system
<ekleog>
(your use case could be covered by making it ? "don't use this value ever ever ever ever (c) infinisil", couldn't it?)
<infinisil>
I guess, but that feels weird
<ekleog>
well, if it could make the language a bit more sane it'd worth it imo :) (yeah, that's not gonna happen anyway :( )
<infinisil>
> let foo = { a ? builtins.currentTime }@s: if a == builtins.currentTime then "a was passed" else "a was not passed"; in foo { a = 10; }
<{^_^}>
"a was not passed"
<infinisil>
> let foo = { a ? builtins.currentTime }@s: if a == builtins.currentTime then "a was passed" else "a was not passed"; in foo {}
<{^_^}>
"a was passed"
<infinisil>
:P
<infinisil>
I guess builtins.currentTime could still just be the argument you pass though
<infinisil>
> :v rand
<{^_^}>
rand = next
<infinisil>
> :v next
<{^_^}>
next = s: lib.mod (1103515245 * s + 12345) 4294967296
<infinisil>
> let foo = let thing = lib.mod (1103515245 * builtins.currentTime + 12345) 4294967296; in { a ? thing }@s: if a == thing then "a was passed" else "a was not passed"; in foo {}
<{^_^}>
"a was passed"
clever has joined #nix-lang
<clever>
infinisil: ok, what else can take an attrset and return it as a flat something
* infinisil
is missing context
<clever>
i'm trying to get nix to leak the order of keys in a set
<clever>
the only difference between these, is the keys for the 1st trace
<clever>
yet the order that mapAttrs runs the 2nd trace, differs
<clever>
but you can only see that leak via the impurity that is stdout and trace
<clever>
internally, nix hides this very well
<infinisil>
Whoa nice
<clever>
so the values of any set nix has previously parsed, will impact the order of keys within all future sets, and impact the order of mapAttrs
<infinisil>
Ahh, so it first traces the toJSON, which fully evaluates the attrset, assigning numbers to names, then mapAttrs loops through those numbers in order?
<clever>
yeah
<infinisil>
builtins.attrNames instead of toJSON works too
<clever>
yeah, anything that forces it in full
<clever>
it may not even need a force, it might just be a side-effect of parsing