@atravers Sadly, yes, it’s bears similarities to DynFlags 🫤 Luckily it’s not quite at that scale though. Most of the flags are bools that fix bugs and should basically only ever be true. But theoretically, yes, exhaustively testing the whole of the application should be tesing 2^N configurations.
The implicit config paper just looks like what the reflection library does. Is there something I’m missing?
@BurningWitness We have a map from flag to value, so we could just add that map as the first argument to every function, even if the function doesn’t use it yet. By “too manual”, I simply mean it’s verbose and annoying to manually thread through everywhere. I did say to assume a greenfield project, but in our actual usecase, it would’ve been infeasible to add an argument to every function in our existing codebase. But I guess theoretically, in a greenfield project, having a convention that every single function should have the first argument be the flags is not terrible.
Unrelated, I wonder how upgrading dependencies work at my work…
And yes, assume that “flipping a flag” only happens if the execution failed and is rerun. Flags are immutable for the life of the program in prod.
@hasufell I’m trying to keep my personal feelings aside. (But I completely agree
)