See ##330753 for the last time a similar thing was attempted by @eclairevoyant.

Declaring previously-undeclared options broke the config.foo or default fallback pattern used throughout nixpkgs because declared options always exist (even if unset), preventing the or operator from using its default value.

Can you read through that PR and make sure you're not falling into the same trap?

Thanks for the heads up! I took a look at #330753 — the issue there was that the declared defaults didn't match the existing fallback values, which broke the or pattern.

In this PR, I made sure to align the defaults with what the code already expects: [] for cudaCapabilities, true for cudaForwardCompat, and null for replaceStdenv. I also updated the check in pkgs/stdenv/default.nix from config ? replaceStdenv to (config.replaceStdenv or null) != null to handle the declared-but-null case.

Verified with nix-build -A tests.config and everything passes.

Hmmm... turns out it's not dead code - CI failed cuz some contexts like tarball builds don't go through the module system, so the attribute doesn't exist there. Let me revert it

Mind adding a comment there in the code, then?

Mind adding a comment there in the code, then?

Done

cc @NixOS/cuda-maintainers who I would think are 👍🏻 on this

In principle I'm okay with this; I do want to warn you that adding types for some options can have unintended consequences via strictness induced by module system checking the types. I ran into some infinite recursion errors when I had tried adding options for allowlistedLicenses and blocklistedLicenses previously.