www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - testing for deprecation

reply Cauterite <cauterite gmail.com> writes:
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.
Sep 01 2016
next sibling parent reply rikki cattermole <rikki cattermole.co.nz> writes:
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!
Sep 01 2016
parent reply jmh530 <john.michael.hall gmail.com> writes:
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?
Aug 25 2017
parent reply user1234 <user1234 12.hu> writes:
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.
Aug 26 2017
parent reply jmh530 <john.michael.hall gmail.com> writes:
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.
Aug 28 2017
parent reply Jonathan M Davis via Digitalmars-d-learn writes:
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
Aug 28 2017
parent jmh530 <john.michael.hall gmail.com> writes:
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!
Aug 28 2017
prev sibling parent reply Sebastien Alaiwan <ace17 free.fr> writes:
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?
Aug 28 2017
parent user1234 <user1234 12.hu> writes:
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.
Aug 29 2017