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

[Sönke Ludwig]

Am 08.10.2019 um 13:50 schrieb 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.

For the particular issue of filtering out deprecated members, I've 
written a little workaround some time ago, using the fact that warnings 
inside of _traits(compiles) are gagged:

https://github.com/s-ludwig/dynamic/blob/79b73a9afe14432da6917fd519563655300092d1/source/dynamic.d#L82-L85

It doesn't help when actual access to these members is desired.