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
