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
Right, as long as it is part of the language and consistent across compilers /
platforms, I don’t think we need to use macros.
> On Jan 24, 2024, at 11:59 PM, Anne van Kesteren wrote:
>
> I had a [[fallthrough]] patch, but internal C code got in the way:
>
> -
I had a [[fallthrough]] patch, but internal C code got in the way:
- https://en.cppreference.com/w/c/language/attributes/fallthrough
- https://bugs.webkit.org/show_bug.cgi?id=265789
Using them directly where we can seems nice for (new) readers of the code at
least. Not sure what a macro for
If we’re adopting [[maybe_unused]], do we just write that directly in each
function declaration / definition? Or do we define some a macro to do that
anyway?
What bout other kinds of attributes like [[noreturn]], [[fallthrough]], and
[[likely]]? Are we gonna start writing them directly in
Hi,
Thanks for starting this discussion.
I personally think it would be nice for us to switch to [[maybe_unused]] since
it is now part of the language and it seems to fit our needs. However, I do
think we should be consistent and stop using UNUSED_PARAM() / ASSERT_UNUSED()
in new code
For many years we have used the UNUSED_PARAM macros, and we have almost 3000 of
them. C++17 introduced [[maybe_unused]] for this purpose, and a few uses of it
are starting to pop up in WebKit. Should we switch, should we transition,
should we allow both, or should we just stick with
6 matches
Mail list logo
