https://issues.dlang.org/show_bug.cgi?id=21892

RazvanN <razvan.nitu1305@gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |razvan.nitu1305@gmail.com

--- Comment #1 from RazvanN <razvan.nitu1305@gmail.com> ---
This seems like a narrow use case. Why not just live with the deprecation? The symbol is going to get removed anyway at some point.

I am saying this because there is no mechanism inside the compiler to skip deprecations depending on context. Also, the behavior would most likely have to be hidden behind a switch since other people might want to issue deprecations when reflecting on deprecated methods. And we all know that Walter is against adding more compiler switches.

This seems like a fairly complicated thing to implement for questionable benefits.

--

https://issues.dlang.org/show_bug.cgi?id=21892

--- Comment #2 from Adam D. Ruppe <destructionator@gmail.com> ---
Those of us who actually use D in the real world have to work around seas of deprecation messages caused by reflection all the time. It becomes a boy who cried wolf. It'd help a lot.

And deprecated symbols are not necessarily removed. The whole point of a deprecation is to say "don't use it". actually removing at that point is redundant breakage.

--

https://issues.dlang.org/show_bug.cgi?id=21892

mhh <maxhaton@gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |maxhaton@gmail.com

--- Comment #3 from mhh <maxhaton@gmail.com> ---
Deprecations ideally should trigger on use. Currently the behaviour is too conservative. Symmetry code can easily print hundreds of useless warnings due to this.

--

https://issues.dlang.org/show_bug.cgi?id=21892

Steven Schveighoffer <schveiguy@gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |schveiguy@gmail.com

--- Comment #4 from Steven Schveighoffer <schveiguy@gmail.com> ---
Just posting my +1.

My vibe project is logging HTTPStatus exceptions. The HTTPStatus enum has deprecated all their members in favor of different names.

see https://github.com/vibe-d/vibe.d/pull/2604

Logging an HTTPStatus exception yields more than 1300 lines of deprecation messages all from *one line of code*, which didn't use the deprecated members specifically. This isn't useful.

In a case like formatValue, it's not going to be affected by the removal of those members at all -- it will adapt just fine, because __traits(allMembers) will not return those members.

I agree with Adam, some way of identifying that your code is immune to deprecated symbols being removed to suppress the printing of deprecation messages.

The thing that defeats the purpose of deprecation messages is having pages and pages of deprecation messages that are invalid. We should at least provide a way to work around that, especially in a language which heavily caters to introspection.

Note especially the comment in the above mentioned PR:

> Note that the deprecated enum members in vibe.data.bson/json cannot realistically be marked as such, as that triggers thousands of deprecation warnings in Phobos when to!T is used together with Json.Type or Bson.Type.

So this problem is actually causing people to NOT USE DEPRECATIONS where they should be used.

--

https://issues.dlang.org/show_bug.cgi?id=21892

ponce <aliloko@gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |aliloko@gmail.com

--- Comment #5 from ponce <aliloko@gmail.com> ---
This is my +1, also hitting this.

In my case, the code that does it is:


        foreach(memberName; __traits(allMembers, aClass))
        {
            alias P = __traits(getMember, aClass, memberName);

            foreach(attr; __traits(getAttributes, P))
            {{
                // stuff
            }}
        }


Ideally there should be a way to:
-  not trigger those deprecation warnings at reflection
- or the ability to get __traits(allMembersNoDeprecated)

--

https://issues.dlang.org/show_bug.cgi?id=21892

--- Comment #6 from ponce <aliloko@gmail.com> ---
> So this problem is actually causing people to NOT USE DEPRECATIONS where they should be used.

Exactly, we are loosing the ability to use "deprecated" in our widget class hierarchy.

--

https://issues.dlang.org/show_bug.cgi?id=21892

Iain Buclaw <ibuclaw@gdcproject.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Priority|P1                          |P4

--