Hmm. CI timed out.

It did not really time out. You are running in a bunch of these errors on Darwin:

2020-03-29T03:50:22.9693600Z lib/Nix/Store.xs:109:55: error: use of undeclared identifier 'Base32'
2020-03-29T03:50:22.9694240Z             auto s = info->narHash.to_string(base32 ? Base32 : Base16);
2020-03-29T03:50:22.9694380Z                                                       ^
2020-03-29T03:50:22.9694870Z lib/Nix/Store.xs:109:64: error: use of undeclared identifier 'Base16'
2020-03-29T03:50:22.9695340Z             auto s = info->narHash.to_string(base32 ? Base32 : Base16);

Oh oops I read the wrong one. Thanks!

OK! this all up date and ready to go.

@edolstra This PR in particular especially clutters up the other more interesting PRs that contain it. It would be great if we could merge it soon. My offer still stands to get rid of any conflicts in the flakes after merging :).

I'm not really in favor of this. It's a huge amount of code churn for no real advantage (as far as I can see). I mean, what's the benefit to writing Verbosity::Info instead of lvlInfo?

My apologies for not expounding "better practice in C++", but it appears according to https://en.cppreference.com/w/cpp/language/enum that these "scoped enumerations" have fewer implicit conversions than their unscoped equivalents. I would think that's some real value as we don't want numbers sneaking through.

In addition, I still find the code with change easier to read:

1. Identifiers beginning with a lower case character usually have much smaller scopes.

2. The common prefix does indicate the variants are for the same enum, but doesn't indicate what which enum that is.

I'd hope one of the main benefits of not keeping a stable API in Nix anyways is that there is little-to-no marginal cost in doing slight cleanups like there. Each one is small, but they'll compound over time. And with my promise to go through any unmerged branch you like to resolve the conflicts, I hope the churn wouldn't impact you at all.

But if you still don't like this, we can close it and I'll go remove it from the other PRs it's included in. That will be tedious, but is self-inflicted on my part, so I'm not asking that it affect your decision.

If we have fix all the lower hanging fruit such that churn like this is deemed with it, I assume it will be easier to just sed afresh from scratch.