Bug 17906 – Deprecated Language features should be allowed without a deprecation in a deprecated scope

Status
RESOLVED
Resolution
WORKSFORME
Severity
enhancement
Priority
P1
Component
dmd
Product
D
Version
D2
Platform
x86_64
OS
Linux
Creation time
2017-10-17T11:48:59Z
Last change time
2022-11-23T09:38:12Z
Keywords
pull
Assigned to
No Owner
Creator
FeepingCreature
Depends on
18647
See also
https://issues.dlang.org/show_bug.cgi?id=18647

Comments

Comment #0 by default_357-line — 2017-10-17T11:48:59Z
Currently I'm running into lots of deprecated warnings on functions that I don't call but that *themselves* use deprecated features. Example: import std.optional; // Optional is deprecated in favor of nullable // foo warns, even if it is not called, because it uses a deprecated feature. // No duh, that's why it's marked 'deprecated'. deprecated void foo(Optional!bool b); In my opinion, D should not generate deprecated warnings for deprecated features used in contexts which are themselves deprecated, since the only way to get to them incurs a deprecated warning *already*, since the user will already be warned about deprecation via the outer "deprecated" tag.
Comment #1 by mathias.lang — 2018-03-21T18:54:45Z
Yeah, put simply, the following code: ``` deprecated void main () { Object o = new Object; delete o; } ``` should compile with `dmd -de test.d` (DMD v2.079) Currently this is done for other deprecated symbols: deprecated functions can call other deprecated functions, use deprecated types, and a deprecated aggregate can have fields of deprecated types... So it should be done for language deprecations as well.
Comment #2 by default_357-line — 2018-03-21T19:00:27Z
That's also true, but my example refers specifically to deprecated functions using deprecated types. However, I labelled the bug report wrong, and your example actually fits it better. :)
Comment #3 by mathias.lang — 2018-03-21T19:16:13Z
Could you paste the message generated ? In your example, I would expect a deprecation to be generated for the import, but not on the actual function declaration.
Comment #4 by default_357-line — 2018-03-21T19:29:48Z
Huh, seems like you're right. Not sure if this was fixed or it always worked that way. Either way, good to know! I guess this bug report is about Mathias Lang's problem now.
Comment #5 by greensunny12 — 2018-03-21T22:37:33Z
> I guess this bug report is about Mathias Lang's problem now. PR https://github.com/dlang/dmd/pull/8066 (and changed the title accordingly)
Comment #6 by greensunny12 — 2018-03-22T16:28:39Z
Copying Mathias's from GH (in case it gets lost) The bug report was more general (before you changed the title). I took delete as an example, because it's what hits me, but I'm pretty sure it affects other deprecations. For example: --- deprecated void main () { int i, o; switch (i) { case 1: o = 1; case 2: o = 2; break; default: } } ---
Comment #7 by razvan.nitu1305 — 2022-11-23T09:38:12Z
I cannot reproduce this. I have used this example: deprecated void main () @safe { toString(null); } deprecated void toString (void delegate (char[]) @safe sink) @safe { char[20] buffer = void; sink(unsignedToTempString(42, buffer)); } With the functions not being deprecated, you get a deprecation about assigning buffer to the anonymous parameter of synk, but with the functions being deprecated the message is silenced. Closing as WORKSFORME.