On 7/22/19 6:53 PM, Martin Sebor wrote: > On 7/22/19 4:19 PM, Jeff Law wrote: >> On 7/8/19 3:58 PM, Martin Sebor wrote: >>> The attached patch implements three new warnings: >>> >>> * -Wstruct-not-pod triggers for struct definitions that are not >>> POD structs, >>> * -Wclass-is-pod triggers for class definitions that satisfy >>> the requirements on POD structs, and >>> * -Wmismatched-tags that triggers for class and struct declarations >>> with class-key that doesn't match either their definition or >>> the first declaration (if no definition is provided). >>> >>> The implementation of -Wclass-is-pod and -Wstruct-not-pod is fairly >>> straightforward but the -Wmismatched-tags solution is slightly unusual. >>> It collects struct and class declarations first and diagnoses mismatches >>> only after the whole tramslation unit has been processed. This is so >>> that the definition of a class can guide which declarations to diagnose >>> no matter which come first. >> So there was some discussion on whether or not we even wanted to keep >> the struct vs class convention for GCC. >> >> Did that reach any kind of conclusion? I don't have a strong opinion >> here and will adjust to whatever the consensus is. > > I'm not really sure how to gauge consensus here but this patch doesn't > actually enforce the GCC convention, it just makes it possible (none > of the new options is included in -Wall or -Wextra; they all have to > be enabled explicitly). I'm not entirely sure either. To a large degree this feels like a case where the C++ leads as well as the major contributors chime in.
How about this, when I get back from PTO if there haven't been objections from the major contributors, then we go forward and change the convention. That givesfolks just shy of 2 weeks to object (I've read Jason and Jon's comments as supporting dropping the existing convention). If there's objections, then we discuss further :-) > > I myself wouldn't adopt a class/struct convention like that if given > the choice and wouldn't be at all upset if we dropped it going forward, > despite all the effort I put into the cleanup (which has already been > committed). But us dropping it won't affect other projects that also > use it(*), albeit without enforcement, and so I would rather not tie > the consideration of the patch to the GCC guideline. I would think > helping other projects enforce it if they find it helpful would be > seen as valuable even if we don't find the convention useful in GCC > anymore. Right. Given this seems to be a convention used elsewhere we could still go forward with your patch to warn, even if we decide against using the convention going forward for GCC. It'd be your call if you want to go forward with the warning patch. Jeff
