Thread overview
testing for deprecation
Sep 01, 2016
Cauterite
Sep 01, 2016
rikki cattermole
Aug 25, 2017
jmh530
Aug 26, 2017
user1234
Aug 28, 2017
jmh530
Aug 28, 2017
Jonathan M Davis
Aug 28, 2017
jmh530
Aug 29, 2017
Sebastien Alaiwan
Aug 29, 2017
user1234
September 01, 2016
How does one test whether a symbol is deprecated? I would have expected something like: __traits(isDeprecated, foo).

In the compiler we have Dsymbol.isDeprecated, is that not accessible in any way from code?

The only solution I can think of is compiling with -de and using __traits(compiles, {alias x = foo;})
which actually does seem to work. Pretty lousy though.
September 01, 2016
On 01/09/2016 11:11 PM, Cauterite wrote:
> How does one test whether a symbol is deprecated? I would have expected
> something like: __traits(isDeprecated, foo).
>
> In the compiler we have Dsymbol.isDeprecated, is that not accessible in
> any way from code?
>
> The only solution I can think of is compiling with -de and using
> __traits(compiles, {alias x = foo;})
> which actually does seem to work. Pretty lousy though.

That is a first that somebody wanted it.
Bug report please!
August 25, 2017
On Thursday, 1 September 2016 at 11:13:42 UTC, rikki cattermole wrote:
>
> That is a first that somebody wanted it.
> Bug report please!

I just ran across this with

deprecated {
    void foo();
}
void main() {
    pragma(msg, __traits(getAttributes, foo));
}

producing just tuple(). I came across this when looping through the members of a module and wanting to skip the deprecated ones.

I did a quick look in Bugzilla and didn't find anything. Do you know if anyone filed anything I may have missed?

August 26, 2017
On Friday, 25 August 2017 at 20:35:52 UTC, jmh530 wrote:
> On Thursday, 1 September 2016 at 11:13:42 UTC, rikki cattermole wrote:
>>
>> That is a first that somebody wanted it.
>> Bug report please!
>
> I just ran across this with
>
> deprecated {
>     void foo();
> }
> void main() {
>     pragma(msg, __traits(getAttributes, foo));
> }
>
> producing just tuple().

getAttributes is made for UDAs only.
August 28, 2017
On Saturday, 26 August 2017 at 07:17:49 UTC, user1234 wrote:
>
> getAttributes is made for UDAs only.

Okay, well if you change it to

deprecated {
    void foo();
}

void main() {
    pragma(msg, __traits(getFunctionAttributes, foo));
}

then you just get

tuple(@system)

so the issue still stands. I see no way to loop through members of a module at compile-time and exclude the ones that are deprecated.
August 28, 2017
On Monday, August 28, 2017 13:08:04 jmh530 via Digitalmars-d-learn wrote:
> On Saturday, 26 August 2017 at 07:17:49 UTC, user1234 wrote:
> > getAttributes is made for UDAs only.
>
> Okay, well if you change it to
>
> deprecated {
>      void foo();
> }
>
> void main() {
>      pragma(msg, __traits(getFunctionAttributes, foo));
> }
>
> then you just get
>
> tuple(@system)
>
> so the issue still stands. I see no way to loop through members of a module at compile-time and exclude the ones that are deprecated.

I think that it's pretty clear that a new traits for __traits would be required. Per the documentation, getFunctionAttributes does not include anything about deprecation, and even if it did, it wouldn't be sufficient anyway, because it would only cover functions, whereas almost any symbol that isn't local to a function can be deprecated (the only case I can think of at the moment where you can't deprecate a symbol that isn't inside a function is enum members, which can't be individually deprecated, because you can't apply any attributes to them individually). We'd probably need something like __traits(isDeprecated, symbol).

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

- Jonathan M Davis

August 28, 2017
On Monday, 28 August 2017 at 21:29:31 UTC, Jonathan M Davis wrote:
>
> I think that it's pretty clear that a new traits for __traits would be required. Per the documentation, getFunctionAttributes does not include anything about deprecation, and even if it did, it wouldn't be sufficient anyway, because it would only cover functions, whereas almost any symbol that isn't local to a function can be deprecated (the only case I can think of at the moment where you can't deprecate a symbol that isn't inside a function is enum members, which can't be individually deprecated, because you can't apply any attributes to them individually). We'd probably need something like __traits(isDeprecated, symbol).
>
> https://issues.dlang.org/show_bug.cgi?id=17791
>
> - Jonathan M Davis

Thanks for filing that!
August 29, 2017
On Thursday, 1 September 2016 at 11:11:15 UTC, Cauterite wrote:
> How does one test whether a symbol is deprecated? I would have expected something like: __traits(isDeprecated, foo).

Such a trait makes it possible to write code that will break, just because something has been marked as deprecated.

Doesn't it break the purpose of deprecation?

August 29, 2017
On Tuesday, 29 August 2017 at 05:03:39 UTC, Sebastien Alaiwan wrote:
> On Thursday, 1 September 2016 at 11:11:15 UTC, Cauterite wrote:
>> How does one test whether a symbol is deprecated? I would have expected something like: __traits(isDeprecated, foo).
>
> Such a trait makes it possible to write code that will break, just because something has been marked as deprecated.
>
> Doesn't it break the purpose of deprecation?

Yeah.

static assert (!__traits(isDeprecated, foo), "i could use the -de switch as well");

I don't see any real-world usage for this trait. That being said the amount of work to implement this in the compiler is trivial. I would tear down the feature + its tests in half an hour i think.