Annoying deprecation messages when using EnumMembers with enum that has deprecated members

[FeepingCreature]

On Tuesday, 8 October 2019 at 10:06:18 UTC, Jonathan M Davis 
wrote:
> A related issue is the -de flag, which arguably is really bad 
> in that it makes it so that is expressions and 
> __traits(compiles, ...) expressions have a different result 
> depending on whether -de is used or not, because -de turns 
> deprecation messages into errors. Meaning that code that 
> compiled just fine before the deprecation may not compile 
> anymore, or it may compile with different behavior.
>

I'm gonna argue this :) -de makes sense if one interprets it as 
"generate the code that would result if all deprecated symbols 
were removed." Of course this doesn't quite work right with stuff 
like final switch and enums... but it works with pretty much 
everything else. (?)

Should __traits(allMembers) ignore deprecated enum members with 
-de? Under this interpretation, it seems that it should.

And regarding expressions having a different result, well, yes, 
just like they'll have when the deprecated symbol is removed. :)

Separately: the problem with unittest and deprecations is that a 
"deprecated unittest" results in a deprecated unittest function 
in __traits(getUnitTests), which there's no way to call without 
incurring recursive deprecation all the way to deprecated void 
main. This is arguably wrong - imo deprecated unittest shouldn't 
mean the *test* is deprecated, just that it tests a deprecated 
feature. This can be seen by the fact that D's runtime calls 
deprecated unittests with no warning, -de or otherwise. So you 
should be able to call them from framework code too.