Fix Issue 21217 - C++ header generator shouldn't emit private enums

[wilzbach]

Required for #11640

[dlang-bot]

Thanks for your pull request, @wilzbach!

Bugzilla references

Auto-close	Bugzilla	Severity	Description
✓	21217	major	C++ header generator shouldn't emit private enums

Testing this PR locally

If you don't have a local development environment setup, you can use Digger to test this PR:

dub run digger -- build "master + dmd#11679"

[MoonlightSentinel]

Not sure about protected enums, Why should they not be accessible across language barriers?

[wilzbach]

Not sure about protected enums, Why should they not be accessible across language barriers?

From the docs:

protected only applies inside classes (and templates as they can be mixed in) and means that a symbol can only be seen by members of the same module, or by a derived class. If accessing a protected instance member through a derived class member function, that member can only be accessed for the object instance which can be implicitly cast to the same type as ‘this’. protected module members are illegal. (https://dlang.org/spec/attribute.html#visibility_attributes)

My reasoning:

• it's better to be conservative and enable a feature when asked for (then the other way around)
• dtoh currently ignores protected (see: https://issues.dlang.org/show_bug.cgi?id=21218)

So I would feel more comfortable emitting protected enums if protected variables were a thing in dtoh, but AFAICT everything emitted is public.

[MoonlightSentinel]

So I would feel more comfortable emitting protected enums if protected variables were a thing in dtoh, but AFAICT everything emitted is public.

Fair enough, this shouldn't be a real breaking change given the state of the header generator. But it needs to be re-enabled once the generator properly emits protection levels.