Add BOUT_ENUM_CLASS_NS and switch bout::ConductionMethod to it

[dschwoerer]

BOUT_ENUM_CLASS_NS is a version of BOUT_ENUM_CLASS that can create namespaced enums

[github-actions]

clang-tidy made some suggestions

[ZedThree]

Might be better/simpler if we just stuck a namespace onto the existing BOUT_ENUM? We can then do either of the following for backwards compatibility:

// bring the Foo name into the current scope
using bout::Foo;
// type alias lets us put a deprecated attribute on it
using Foo [[deprecated("use bout::Foo")]] = bout::Foo;

[ZedThree]

Probably the std::int8_t can also be changed to std::uint8_t, I seem to recall it always triggers clang-tidy warnings

[dschwoerer]

Might be better/simpler if we just stuck a namespace onto the existing BOUT_ENUM? We can then do either of the following for backwards compatibility:

// bring the Foo name into the current scope
using bout::Foo;
// type alias lets us put a deprecated attribute on it
using Foo [[deprecated("use bout::Foo")]] = bout::Foo;

I think it might make sense to introduce the new namespaced enum first, and test it, before we do a lot of churn?

Probably the std::int8_t can also be changed to std::uint8_t, I seem to recall it always triggers clang-tidy warnings

It should probably be unsigned, but I think clang-tidy is happy with this one. It was not happy with int - which is the default and the reason I switched to an 8bit type in d170774.

[ZedThree]

What needs testing? It's just putting the declaration into a namespace -- if it compiles, the existing tests should be sufficient?

[dschwoerer]

If the tests cover everything, than that is probably true.

It is still a lot of churn, and I do not fancy doing it right now, especially if we deprecate the old version (which we should) and switch everywhere away from it (to avoid more warnings).

[bendudson]

For my understanding, what's the difference between this and just using

namespace bout {
  BOUT_ENUM_CLASS(myclass, ...);
}

rather than

BOUT_ENUM_CLASS_NS(bout, myclass, ...)

Edit: Ah I see: specializations of toString, Options::as shouldn't be in the namespace.

[ZedThree]

I mean, they probably should be in the bout namespace, we're very inconsistent on this point!