We already have mozilla::Unused in mfbt/Unused.h. You can use it as `mozilla::unused << SomethingReturningAValue();`. I believe that the existing static analyses which look at unused variables respect this.
On Tue, Aug 23, 2016 at 9:47 AM, Eric Rescorla <e...@rtfm.com> wrote: > Fair enough. I wouldn't be against introducing a separate unused marker for > this purpose. > > -Ekr > > > On Tue, Aug 23, 2016 at 6:40 AM, Benjamin Smedberg <benja...@smedbergs.us> > wrote: > > > 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 > _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
