cast-to-void is commonly suggested as an alternative to an explicit unused marking, and it is something that I wanted to use originally. Unfortunately, we have not been able to make that work: this is primarily because compilers often remove the cast-to-void as part of the parsing phase, so it's not visible in the parse tree for static checkers.
--BDS On Tue, Aug 23, 2016 at 9:19 AM, Eric Rescorla <e...@rtfm.com> wrote: > I'm indifferent to this particular case, but I think that rkent's point > about static > checking is a good one. Given that C++ has existing annotations that say: > > - This does not produce a useful return value (return void) > - I am explicitly ignoring the return value (cast to void) > > And that we have (albeit imperfect) static checking tools that can detect > non-use of > return values, it seems like we would ultimately be better-off by using > those tools > to treat use of the return value by the default flagging a compiler error > when that > doesn't happen yet a third annotation rather than treating "use the return > value > somehow" as the default and flagging a compiler error when that doesn't > happen. > I appreciate that we have a lot of code that violates this rule now, so > actually cleaning > that up is a long process gradually converting the code base, but it has > the advantage > that once that's done then it just stays clean (just like any other -Werror > conversion). > > -Ekr > > > On Mon, Aug 22, 2016 at 5:03 PM, Bobby Holley <bobbyhol...@gmail.com> > wrote: > > > On Mon, Aug 22, 2016 at 4:39 PM, R Kent James <k...@caspia.com> wrote: > > > > > On 8/21/2016 9:14 PM, Nicholas Nethercote wrote: > > > > I strongly encourage people to do likewise on > > > > any IDL files with which they are familiar. Adding appropriate checks > > > isn't > > > > always easy > > > > > > Exactly, and I hope that you and others restrain your exuberance a > > > little bit for this reason. A warning would be one thing, but a hard > > > failure that forces developers to drop what they are doing and think > > > hard about an appropriate check is just having you set YOUR priorities > > > for people rather than letting people do what might be much more > > > important work. > > > > > > There's lots of legacy code around that may or may not be worth the > > > effort to think hard about such failures. This is really better suited > > > for a static checker that can make a list of problems, which list can > be > > > managed appropriately for priority, rather than a hard error that > forces > > > us to drop everything. > > > > > > > I don't quite follow the objection here. > > > > Anybody who adds such an annotation needs to get the tree green before > they > > land the annotation. Developers writing new code that ignores the > nsresult > > will get instant feedback (by way of try failure) that the developer of > the > > API thinks the nsresult needs to be checked. This doesn't seem like an > > undue burden, and enforced-by-default assertions are critical to code > > hygiene and quality. > > > > If your concern is the way this API change may break Thunderbird-only > > consumers of shared XPCOM APIs, that's related to Thunderbird being a > > non-Tier-1 platform, and pretty orthogonal to the specific change that > Nick > > made. > > > > bholley > > > > > > > > > :rkent > > > _______________________________________________ > > > dev-platform mailing list > > > dev-platform@lists.mozilla.org > > > https://lists.mozilla.org/listinfo/dev-platform > > > > > _______________________________________________ > > dev-platform mailing list > > dev-platform@lists.mozilla.org > > https://lists.mozilla.org/listinfo/dev-platform > > > _______________________________________________ > dev-platform mailing list > dev-platform@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-platform > _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
