On Thu, 8 Aug 2024, Alejandro Colomar wrote: > How about having __lengthof__ behave like sizeof, but deprecate it in > sizeof too?
Deprecation would be a matter for WG14. > We could start by adding a -Wall warning for sizeof without parens, and > promote it to an error a few versions later. This is very far outside the scope of -Wall. There is nothing confusing for the programmer about sizeof without parentheses and no likelihood that the programmer meant something other than the semantics of the code. GCC should not be opinionated about promoting personal ideas of what is or is not good style or what might or might not be a future language feature; it should support a wide range of different programming styles. The threshold for warning about something in -Wall (or -Wextra) should be much higher than "the language design would be simpler without this feature". > P.S.: I'm doing a whole-tree update to use __lengthof__ instead of > open-coded sizeof divisons or macros based on it, and I've found several > bugs already. I'll use this change to test the new operator in the > entire code base, which should result in no regressions at all. That > would be an interesting test suite. :) I think the code base (code on the host is generally in C++) should be readable to people who know C++ (C++11 is the documented requirement for building GCC - we're very conservative about adopting new language versions, to facilitate bootstrapping on a wide range of systems) as it is, not a playground for trying out new language features. We have enough GCC-specific versions of standard features as it is (e.g. the GCC-specific vectors designed to interoperate with GCC's garbage collection), using a new feature that doesn't add expressivity and isn't in any standard C++ version doesn't seem like a good idea to me. Actual bugs should of course be fixed. But certainly standard features are preferable to something specific to GCC, and existing macros in GCC such as ARRAY_SIZE that people are at least familiar with are preferable to introducing a new language feature. *If* the feature were adopted into C++26, we could then consider if existing macros should be renamed to look more like the future language feature. Target code is at least always compiled with the same version of GCC, but it still shouldn't be a playground for new language features; that doesn't help readability, backporting patches to versions without the features, etc. -- Joseph S. Myers josmy...@redhat.com
