Re: [PATCH 0/3] add support for POD struct convention (PR 61339)

[Jason Merrill <jason@redhat.com>]

On Fri, Jul 12, 2019 at 7:42 AM Jonathan Wakely <jwakely@redhat.com> wrote:
>
> On 12/07/19 10:24 +0200, Jakub Jelinek wrote:
> >On Mon, Jul 08, 2019 at 03:56:51PM -0600, Martin Sebor wrote:
> >> A couple of GCC's Coding Conventions call to
> >>
> >>   1) Use the struct keyword for plain old data (POD) types.
> >>      https://www.gnu.org/software/gcc/codingrationale.html#struct
> >>
> >> and
> >>
> >>   2) Use the class keyword for non-POD types.
> >>      https://www.gnu.org/software/gcc/codingconventions.html#Class_Use
> >
> >This is a coding convention that has been added without any discussion
> >whatsoever on that, maybe it was some Google internal coding convention or
> >something, do we really want to enforce it rather than discuss
> >and decide what we actually want?
> >
> >With my limited C++ knowledge, the main distinction between struct and class
> >when both can appear interchangeably is that struct defaults to public:
>
> The default applies to class members and base classes, but that's the
> *only* distinction.
>
> >and class defaults to private:, and I think it is best to use those that
> >way, rather than having tons of class ... { public: ... } everywhere.
> >
> >There are many C++ class boolean properties, rather than just
> >POD vs. non-POD and we could pick any of them instead of this particular one
> >for the struct vs. class distinction if we wanted to enforce it, but why?

I agree.  The class-key used to define a class has very little signalling value.

> I'm also unconvinced that POD is a useful distinction. A class might
> be a POD today, but then we decide to add a default constructor to it
> (or if/when we move to C++11, add default member initializers to it).
> Does that mean we need to replace struct with class to follow this
> convention?
>
> Or we might decide to add a std::string member to it, which stops it
> being a POD. Should every reference to it be changed from struct to
> class?

Indeed.

> Personally I think "no user-defined constructors" might be a more
> useful distinction than POD. This is not a POD (because of the
> std::string member) but I don't see why it should be a class not a
> struct:
>
> struct A {
>   std::string name;
>   int id;
> };

In other words, "aggregate".

But I'm not sure even that is useful as a rule.  If someone wants to
add a constructor to their aggregate to allow parenthesized
initialization, but otherwise use the data members directly, having to
add "public:" at the top is useless boilerplate.

> >I'd just arrange that when being compiled with clang we compile with
> >-Wno-mismatched-tags to get rid of their misdesigned warning

Perhaps, but we might as well use the same tag.

Jason