D issues are now tracked on GitHub. This Bugzilla instance remains as a read-only archive.
Issue 17906 - Deprecated Language features should be allowed without a deprecation in a deprecated scope
Summary: Deprecated Language features should be allowed without a deprecation in a dep...
Status: RESOLVED WORKSFORME
Alias: None
Product: D
Classification: Unclassified
Component: dmd (show other issues)
Version: D2
Hardware: x86_64 Linux
: P1 enhancement
Assignee: No Owner
URL:
Keywords: pull
Depends on: 18647
Blocks:
  Show dependency treegraph
 
Reported: 2017-10-17 11:48 UTC by FeepingCreature
Modified: 2022-11-23 09:38 UTC (History)
3 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this issue.
Description FeepingCreature 2017-10-17 11:48:59 UTC
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 Mathias Lang 2018-03-21 18:54:45 UTC
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 FeepingCreature 2018-03-21 19:00:27 UTC
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 Mathias Lang 2018-03-21 19:16:13 UTC
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 FeepingCreature 2018-03-21 19:29:48 UTC
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 Seb 2018-03-21 22:37:33 UTC
> 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 Seb 2018-03-22 16:28:39 UTC
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 RazvanN 2022-11-23 09:38:12 UTC
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.