lib: add xor

[edef1c]

Description of changes

This gets clumsily reimplemented in various places, to no useful end.

Things done

• Built on platform(s)
  • x86_64-linux
  • aarch64-linux
  • x86_64-darwin
  • aarch64-darwin
• For non-Linux: Is sandboxing enabled in nix.conf? (See Nix manual)
  • sandbox = relaxed
  • sandbox = true
• Tested, as applicable:
  • NixOS test(s) (look inside nixos/tests)
  • and/or package tests
  • or, for functions and "core" functionality, tests in lib/tests or pkgs/test
  • made sure NixOS tests are linked to the relevant packages
• Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
• Tested basic functionality of all binary files (usually in ./result/bin/)
• 24.05 Release Notes (or backporting 23.05 and 23.11 Release notes)
  • (Package updates) Added a release notes entry if the change is major or breaking
  • (Module updates) Added a release notes entry if the change is significant
  • (Module addition) Added a release notes entry if adding a new NixOS module
• Fits CONTRIBUTING.md.

---

Add a 👍 reaction to pull requests you find important.

[infinisil]

xor is the same as != for booleans, so we don't even need a new lib function :D

[edef1c]

xor is the same as != for booleans, so we don't even need a new lib function :D

I don't disagree, but explicitly naming it xor helps ensure people don't reach for strange hacks. It's not a strict necessity, but more of a UX affordance so silly stuff doesn't get written.

Take a look at the diff for the three different overly-complicated xor impls I came across. Perhaps consider it just filling out the missing piece in lib.{and,or} vs lib.bit{And,Or,Xor}.

This implementation also ensures that the arguments are in fact booleans by inverting them, which is invariant under xor anyway. It seems easy for x != y to accidentally fail to ensure there's not some weird typing going on.

[infinisil]

Fair enough, makes sense! Let's have a code comment explaining the ! though, because that's not obvious. Also I'd appreciate a test or two, see

nixpkgs/lib/tests/misc.nix

Lines 205 to 215 in 053ab7f

	/*
	testOr = {
	expr = or true false;
	expected = true;
	};
	*/
	testAnd = {
	expr = and true false;
	expected = false;
	};

.

[edef1c]

I'd appreciate a test or two

Added, whole truth table and all.

Let's have a code comment explaining the ! though, because that's not obvious.

Seems just as obvious to me as the rest, which I suppose means it needs pointing out :p
Comment added.

[infinisil]

Looking good, thanks!