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

[Jonathan M Davis]

On Wednesday, October 9, 2019 8:32:36 AM MDT Gregor Mückl via Digitalmars-d 
wrote:
> On Tuesday, 8 October 2019 at 10:06:18 UTC, Jonathan M Davis
>
> wrote:
> > So, there are a number of subtleties to this whole situation
> > that make it kind of hard to figure out what the best approach
> > is. We don't want deprecation messages being printed when the
> > code isn't really doing anything that needs to be changed, but
> > we also don't want the code's behavior to change just because
> > something was deprecated. And how to tweak what we're doing to
> > fix that in a reasonable way is not obvious.
>
> Would it help to be able to explicitly suppress these warnings in
> certain regions of code? So e.g. std.conv.to could disable these
> warnings when iterating over enum members. Other code that is
> generic and cannot opt out of handling deprecated things could be
> expected to do the same. This shifts the onus from the compiler
> to the programmer. But given the complexity of the issue, it
> might be the right choice.

AFAIK, it's not currently possible to surpress deprecation messages other
than turning them off entirely.

As for whether it would be desirable... I don't know. On the one hand, it's
kind of annoying that something like std.conv.to would spit out deprecation
messages for things like deprecated enum members. On the other hand, that
happens because the code is actually using those deprecated enum members,
and it's quite possible that it will be passed an enum value equal to a
deprecated enum member. Enum members get a bit weird, because deprecating
them doens't necessarily mean that their values are being deprecated, and
even if the values are supposed to go away, it's quite easy to have enum
values that don't match any members (personally, I wish that our enums were
a lot stricter about that than they are, but they aren't).

Normally, deprecation messages indicate that something needs to be updated
to no longer use a deprecated symbol, because that symbol is going to be
removed later. However, in the case of generated code, it could end up using
a deprecated symbol thanks to something like EnumMembers, and yet such code
shouldn't actually be changed. It's just going to naturally take care of
itself once the deprecated enum member is gone. So, on that basis, the
deprecation message is arguably inappropriate, but making it possible to
selectively ignore deprecation messages in such code could be problematic as
well. For instance, consider the case where opCast is deprecated. That would
result in a deprecation message from std.conv.to, but it's one where the
caller would almost certainly need to be updated to not use std.conv.to
(though that could get a bit murky if the idea was that std.conv.to would
switch to using a constructor once the opCast was removed). So, at minimum,
it's not the case that std.conv.to should just be eating deprecation
messages.

Even if we did decide that we wanted to add a way to selectively ignore
deprecation messages, I don't know what that should look like, and depending
on what it looked like, it could have other negative consequences.

Honestly, I suspect that in the vast majority of cases, the current
situation is not an issue. It's popped up now primarily because of the new
ability to deprecate enum members, and while I think that it's great to be
able to do so, I also think that deprecating enum members gets a bit iffy
once things like EnumMembers come into play anyway. Certainly, generated
code like that needs to continue to use deprecated symbols, otherwise it
would break existing code, meaning that it can't actually be updated the way
that you would normally update code using deprecated symbols, and there's a
real risk that once the symbol is actually removed, code will end up
breaking due to the symbol then being gone. So, I don't know how much sense
it makes to deprecate enum members in practice much as it's desirable in
theory.

Personally, the place that I've primarily had issue with needing to use
deprecated symbols in code that isn't deprecated is in template constraints
that are trying to disallow a deprecated type. In particular, last time I
tried to deprecate TickDuration, I ran into problems with a bunch of
deprecation messages that I had a hard time figuring out how to get rid of.

It may be that we need to make some kind of change here with regards to when
deprecation messages pop up and/or how the programmer can control that, but
I'm not sure that we really understand the situation well enough to do a
good job with that at the moment. I think that we need to have a good
understanding of the situations where deprecation messages are popping up
when the code doesn't actually need to be changed - both what's happening
and why - before we can really put forward a good solution to the problem.

- Jonathan M Davis