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
