Re: __attribute__ ((deprecated))

[Tim Hollebeek <tim at hollebeek dot com>]

On Tue, Apr 24, 2001 at 11:47:26AM -0600, Tom Tromey wrote:
> >>>>> "Anthony" == Anthony Green <green@redhat.com> writes:
> 
> >> Philipp wrote:
> >> With the compiler it wouldn't be such a problem. Mark the message
> >> with N_()
> >> (which would mark it as translatable string and thus it would appear in
> >> gcc.pot) and have the compiler call gettext.
> 
> Anthony> Are you sure?  I guess I don't understand GCC's i18n support.
> Anthony> Stan's proposal has part of the message in the user's source
> Anthony> code.  How would that ever end up in gcc.pot?
> 
> I don't see how it could.
> 
> Note that we already have this problem in gcj, because like other Java
> compilers gcj will recognize `@deprecated' in javadoc comments and
> print a message -- which might include user text.
> 
> For C and C++, is arbitrary text really needed?  What if we allowed:
> 
>     int foo (int) __attribute__ ((deprecated "bar(int)"));
> 
> ... and then used `printf ("%s is deprecated; use `%s' instead")
> 
> This would solve the i18n problem at the loss of some generality.  Is
> the generality really a requirement?

I'd rather not see useful functionality be lost because of an i18n
problem.  Some functions are deprecated because they are out of date;
others are deprecated because they have severe security implications.
There should be a mechanism to convey this information to the user,
even if it has to be in English.