On Sun, 2011-12-18 at 19:29 +0100, Anton Khirnov wrote: > On Sun, 18 Dec 2011 19:53:00 +0200, Uoti Urpala <[email protected]> > wrote: > > On Sun, 2011-12-18 at 17:20 +0000, Mans Rullgard wrote: > > > - int age; > > > + attribute_deprecated int age; > > > > IMO setting attribute_deprecated immediately is a bad idea. Unless you > > want your application to break when used with libavcodec compiled > > yesterday you can't remove mentions of the field immediately. Thus > > warnings like this produce clutter that only hides real issues unless > > you disable deprecation warnings completely or add redundant version > > checks. In this case removing code setting the field now rather than > > later doesn't even give any benefit whatsoever: setting it causes no > > harm and there is no new API to test. > > > > If we don't mark it as deprecated, how are the users supposed to notice > it is?
So a user checks compiler warnings and notices that it is deprecated. He determines that the correct action is to do nothing for now. Then there's a warning again the next time he compiles the program. Is the user really supposed to notice it again every day for the next half a year? Adding an entry to APIchanges is a more appropriate way to communicate this (this was missing from Måns's patch). Unconditional attribute_deprecated can be used once it's appropriate to expect the users to actually remove use of the deprecated symbol when they see the warning. _______________________________________________ libav-devel mailing list [email protected] https://lists.libav.org/mailman/listinfo/libav-devel
