Add getVisibility trait as an alias to getProtection

[Geod24]

The name is more accurate and can be recommended in the documentation in the future.

[dlang-bot]

Thanks for your pull request, @Geod24!

Bugzilla references

Your PR doesn't reference any Bugzilla issue.

If your PR contains non-trivial changes, please reference a Bugzilla issue or create a manual changelog.

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#12089"

[adamdruppe]

Does it work cross module now? There was talk before about changing it to do (aggr, "name") as a string instead of aggr.name because of that.

I don't remember if that was already changed to work regardless but if not this would be a good chance to adjust that too.

[Geod24]

I don't remember if that was already changed to work regardless but if not this would be a good chance to adjust that too.

True. Another thing that comes to mind is package visibility. Currently there is no way to know what package it's visible from.
I'm not a user of it myself so I can't tell what are the main use case, but would a __traits(isVisibleFrom, SymbolTested, SymbolFrom) be perhaps a better fit ?

[WalterBright]

Does it work cross module now?

Behavior changes must be in a separate PR.

[adamdruppe]

On Fri, Jan 01, 2021 at 06:23:09PM -0800, Walter Bright wrote: Behavior changes must be in a separate PR.

If you're introducing a new name, that's a good opportunity to fix design flaws without any breaking changes. Keep the old name the same and make the new name fix things. If you introduce the new name first, then any fixing of its design becomes a breaking change. So we should make sure the design is OK before rushing ahead. But that said it seems to be ok now anyway... traits(getMember) bypasses the visibility check so I think the current behavior is OK...