In introspection code, often just enumerating the members of a type with deprecated members will issue deprecated warnings.
We'd need a pragma(deprecated, false) directive to temporarily disable deprecation messages. Then pragma(deprecated, restore) to restore to its set value.
Comment #1 by uplink.coder — 2020-06-26T22:39:14Z
perhaps it should be pargma(push, deprecated, false) then.
together with pragma(pop, deprecated)?
Comment #2 by andrei — 2020-06-27T02:36:50Z
Another idea from Stefan was to control this programmaticaly:
static if (deprecated(symbol)) {
... avoid ...
}
Comment #3 by aldacron — 2020-06-27T07:16:55Z
I like:
pragma(mute, deprecation)
// blah
pragma(unmute, deprecation)
This could then be generalized to apply to other specific warnings in future if the need arises.
Comment #4 by b2.temp — 2020-06-27T08:19:21Z
(In reply to Andrei Alexandrescu from comment #2)
> Another idea from Stefan was to control this programmaticaly:
>
> static if (deprecated(symbol)) {
> ... avoid ...
> }
this could be a property instead, working on types and symbols and why not everything (to avoid branches in metaprog)
static if (symbol.deprecated){}
just like, `.tupleof`, `.mangleof`, etc...
But there's also the option that is not to allow abuse just because of one use case and fix the use case instead, concretly: exclude deprecated symbol from __traits(all,Members), if this is only about this. Or Add a 3rd optional parameter to __traits(allMembers), which would be a set of flag, for now only telling if deprecations have to ignored...
Comment #5 by rmanth — 2020-06-27T08:49:07Z
Scoped pragmas using push and pop is definitely the most robust pragma solution. This is a very common pattern in C++ compilers and could be a useful pattern for other things too.
While excluding deprecated symbols from __traits(allMembers) (and presumably also __traits(getOverloads)), or something like a deprecated(symbol) would help avoid accidentally dealing with deprecated code during introspection, there are other cases that I think only the pragma can help with. For example, we have a library that has test cases using creal because we need to know it works with complex primitives for compatibility. We know it's deprecated and we don't need to be told about it all the time.
Comment #6 by stanislav.blinov — 2020-06-27T12:15:44Z
(In reply to Andrei Alexandrescu from comment #2)
> Another idea from Stefan was to control this programmaticaly:
>
> static if (deprecated(symbol)) {
> ... avoid ...
> }
Yeah, we can kind of do this already, though it's a mouthful:
static foreach (name; __traits(allMembers, Foo))
{
static if (!__traits(isDeprecated, __traits(getMember, Foo, name)))
{{
alias sym = __traits(getMember, Foo, name);
}}
}
Comment #7 by andrei — 2020-06-27T14:19:37Z
(In reply to Stanislav Blinov from comment #6)
> (In reply to Andrei Alexandrescu from comment #2)
> > Another idea from Stefan was to control this programmaticaly:
> >
> > static if (deprecated(symbol)) {
> > ... avoid ...
> > }
>
> Yeah, we can kind of do this already, though it's a mouthful:
>
> static foreach (name; __traits(allMembers, Foo))
> {
> static if (!__traits(isDeprecated, __traits(getMember, Foo, name)))
> {{
> alias sym = __traits(getMember, Foo, name);
> }}
> }
Forgot about that, thanks!
Comment #8 by pro.mathias.lang — 2020-06-27T16:26:21Z
> Yeah, we can kind of do this already, though it's a mouthful:
> [...]
Using `__traits(isDeprecated)` sounds much more reasonable to me, as it only apply to one symbol.
Yes it will push some ugliness in user code, but I can completely see `pragma(deprecated, false)` being misused. What happens when the code that does introspection uses a Phobos function that gets deprecated, or even worse, a language feature ?
An improvement on the current state would be a way to filter them out in the static foreach, a la`static foreach (V; Filter!(isNotDeprecated, __traits(allMembers, aggr)))`.
Comment #9 by robert.schadek — 2024-12-13T19:09:46Z