Re: testing for deprecation
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.
Re: testing for deprecation
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?
Re: testing for deprecation
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!
Re: testing for deprecation
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
Re: testing for deprecation
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.
Re: testing for deprecation
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.
Re: testing for deprecation
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?
Re: testing for deprecation
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!
testing for deprecation
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.
