how does nix handle these differently when it comes to laziness?

let
  inherit (builtins) isInt genList;
  assertMsg = pred: msg: pred || throw msg;
  v1 =
    x:
    assert isInt x || throw "error message";
    x * 2;
  v2 =
    x:
    assert assertMsg (isInt x) "error message";
    x * 2;
  indices = genList (i: i) 100;
in
map v2 indices

i understand that assertMsg and similar functions (throwIf, warnIf, etc) are bad for performance - i can run stats on both versions and tell you that we go from 7 -> 107 thunks, 200 -> 400 function calls, and 4300 -> 7500 envs.bytes when using v2. what i don't get is how we're able to only have 7 thunks in the || case. how do we not need to create a thunk on every call?

I noticed in the repl that there is a builtins.unsafeDiscardOutputDependency. Is it new?

It seems extremely similar to builtins.unsafeDiscardStringContext, so I'm wondering what the difference is and when I might choose one over the other, or if I'd ever need to apply both?

nix-repl> :doc builtins.unsafeDiscardStringContext
Synopsis: builtins.unsafeDiscardStringContext s

Discard the string context from a value that can be coerced to a string.

nix-repl> :doc builtins.unsafeDiscardOutputDependency
Synopsis: builtins.unsafeDiscardOutputDependency s

Create a copy of the given string where every derivation deep string context
element is turned into a constant string context element.

This is the opposite of builtins.addDrvOutputDependencies.

This is unsafe because it allows us to "forget" store objects we would have
otherwise referred to with the string context, whereas Nix normally tracks all
dependencies consistently. Safe operations "grow" but never "shrink" string
contexts. builtins.addDrvOutputDependencies in contrast is safe because
"derivation deep" string context element always refers to the underlying
derivation (among many more things). Replacing a constant string context
element with a "derivation deep" element is a safe operation that just
enlargens the string context without forgetting anything.

There's also the derivation attr unsafeDiscardReferences, which seems to apply mostly to the serialized structured attrs?