I support using standardized and widely enough available language features directly instead of through macros whenever we can. It’s similar to when we drop our own classes and use the ones from the C++ standard, which I think has been good for the project.
It’s also fine with me to use the style checker script to catch mistakes and help educate contributors about this once we’ve decided. Not sure others agree with this, but I’d even support using global replace to move from old style to new style. One nice thing about language features is we don’t have to be so careful about not using them in headers. We don’t want to pull in lots of our own macros into headers that are used outside the project. It’s great for the long term health of the project to cut down the number of unique special things you need to know to understand and work with the code. I have two thoughts about possible reasons for caution as we do these transitions: Macros can be a flexible solution to cross-platform or cross-language issues. It would be a shame to move to a new language feature and discover only afterward that we as a project want to continue to support at least one compiler or platform that doesn’t have a good implementation yet, or support using some header from C, or that there was something else we can work around with macros. This would make me want to do some testing first on each of these before taking the plunge. We should be open to the possibility that some of our macros may still be better solutions to a problem than directly using the new language feature. For example, it is possible that ASSERT_UNUSED is slightly better for its purpose than [[maybe_unused]] since it has a more specific purpose. Marking the argument [[maybe_unused]] when we specifically know it’s only used for assertions isn’t perfect. Of course, ASSERT_UNUSED doesn’t quite do what we’d want either, but it’s still more specific than just saying “maybe”. The unused argument warning macros aren’t superb right now. It’s almost always better to leave out argument names instead of using them, because then there is no “maybe” about it. Unfortunately, the unused argument warning is mostly not turned on outside JavaScriptCore and WebCore. Also, it’s easy to have stale “unused” markings on things that are actually always used, so we leave behind macros that are both no longer needed and subtly misleading. I’m pretty sure [[maybe_unused]] is nearly identical in its properties to UNUSED_PARAM, so none of this really seems like an argument against that. And I’m not sure ASSERT_UNUSED is actually good enough to keep, despite these considerations. I agree with moving in the direction of using these. — Darin _______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
