https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61754

--- Comment #4 from Daniel Krügler <daniel.kruegler at googlemail dot com> ---
(In reply to Martin Sebor from comment #3)
> I find the [[deprecated]] behavior for the test cases here reasonable and
> useful: the struct type is declared deprecated and so its subsequent uses
> are diagnosed.

In general I would agree, but not here, because the second usage (old2) itself
is deprecated. This is a scenario that happens rather often: An older API get's
deprecated and part of that old API was Old2 and old2. You have provided a new
API (Not shown in the examples), but for a while you want to support the old,
deprecated API. What you want to realize is that the *user* of the old API
get's the warning. But now the plain declaration of the old API get's this
warning, too. THis is IMO annoying and the attribute behaviour seems preferable
to me.

> What I think is missing is a way for the author of a deprecated type (but
> not its users) to define objects of the type without triggering the warning,
> analogous to how it can be done for functions.  

Yes, that's what I was trying to argue about above.

I would expect the following
> to do it but it doesn't:
> 
> $ cat u.C && gcc -S -Wall -Wextra -Wpedantic u.C
> struct S { };
> 
> S a [[deprecated]];        // expect no warning here
> 
> struct [[deprecated]] S;   // nor here
> 
> S b;                       // expect -Wdeprecated-declarations here

I agree, but this is different from my example where b itself is also declared
deprecated.

> // Expected behavior:
> 
> int f () { return 0; }
> 
> [[deprecated]] int i = f  ();   // no warning
> 
> [[deprecated]] int f ();        // no warning
> 
> int j = f ();                   // -Wdeprecated-declarations
> u.C:5:23: warning: type attributes ignored after type is already defined
> [-Wattributes]
>  struct [[deprecated]] S;   // nor here
>                        ^
> u.C:18:12: warning: ‘int f()’ is deprecated [-Wdeprecated-declarations]
>  int j = f ();                   // -Wdeprecated-declarations
>             ^
> u.C:12:5: note: declared here
>  int f () { return 0; }
>      ^
> Daniel, does this make sense to you?

These two latter examples make sense to me, but not the behaviour for my case.

Reply via email to