One quick fix that can help mitigate this is to allow reading an environment variable like HASHABLE_DEFAULT_SALT with unsafePerformIO that one can set differently for their application.

This is SO hacky that we shouldn't even merge the PR, just have people use the open PR if necessary. IMO

✨ This is an old work account. Please reference @brandonchinn178 for all future communication ✨

I disagree that it's "SO" hacky. Using environment variables to configure upstream behavior is not uncommon (SYSTEM_CERTIFICATE_PATH for x509-system or http_proxy for http-client). unsafePerformIO isn't terribly hacky if used correctly, in this case to do one-time IO setup actions.

wouldn't setting HASHABLE_RANDOM_SEED work?

Apparently, this works:

cabal new-run hashable-examples -f random-initial-seed

It doesn't give the ability for configuring it, but I think you don't want to configure it anyway, just let it be random on boot.

@jappeace yes that's a (very short-term) workaround.

✨ This is an old work account. Please reference @brandonchinn178 for all future communication ✨

It doesn't give the ability for configuring it, but I think you don't want to configure it anyway, just let it be random on boot.

Yes, I mentioned that in the beginning

The -frandom-init-seed flag helps with this at the cost of a different seed every start up.

But in some situations, you don't want it to be random on boot, such as when you need deterministic tests.