Compilers don't compile declarations in the standard.

My point is that the aforementioned usage can be irritating. Also, yes they do, as the declarations are put into headers by compiler-devs that themselves are compiled when including them - unless I'm mistaken? (Of course, standard headers don't produce warnings, but a specialization of tuple_size necessarily does, which is annoying!)

Compilers do not compile the standard, they compile headers that come with their implementation. The implementation headers can use whatever class-keys they want to, they don't have to match the standard, and changing the standard doesn't mean implementations will change.
I see nothing worth fixing here.

Nor do I, I use class and struct interchangeably (I don't like class with struct-like layout for example, with no private members, etc). If any compiler I use were to warn about that I would just use a compiler flag to silence such warning.

Users who tolerate those bogus warnings should find something more productive to do.

-------- Original message --------
From: Francisco Lopes notifications@github.com
Date: 08/27/2015 9:54 AM (GMT-08:00)
To: cplusplus/draft draft@noreply.github.com
Subject: Re: [draft] Inconsistent class-key in class template declarations
(#534)

Nor do I, I use class and struct interchangeably (I don't like class with struct-like layout for example, no private members, etc). If any compiler where to warn about that I would just use a flag to silent such warning.

—
Reply to this email directly or view it on GitHub.

Closing; while consistency in presentation is generally important, in this case I don't think the comprehensibility or style of the standard is affected.

I've captured the original intent of the issue re-reading it now... Well in that case it seems understandable, but it's bogus nonetheless. Personally I use class and struct interchangeably with a purpose as I said. In this case deviation from the original template in the specialization doesn't look purposeful but there's no rule one can really form about that. Such warnings woudn't apply for me for example, since any specialization may happen to be more class-like or struct-like, and I use the proper keyword in each case, regardless of the keyword used for the original template.

@zygoloid It might be sensible to uncouple-Wmismatched-tags from -Wall then, for Clang. (You can do that, right?)

Edit: Hmm, a bit of research reveals that this is partially relevant for linking, as the VS ABI appears to link struct and class differently. Still seems that having to activate it explicitly is more sensible, though.

@Arcoth, I still don't understand why you think the use of struct or class here in the standard has anything to do with warnings from your compiler. How we present this information in the standard does not dictate how vendors implement those specializations. If you get warnings complain to your std::lib vendor, but this is not the right venue.

I still don't understand why you think the use of struct or class here in the standard has anything to do with warnings from your compiler.

I don't (anymore).

If you get warnings complain to your std::lib vendor, but this is not the right venue.

I was talking about Clang's nonsensical warning that annoyed me, which was the original incentive for opening this issue. I asked a Clang dev above whether removing it from -Wall is sensible - but apparently OT isn't welcome here. I'll ask somewhere else then.

You do realize this is not the place to ask your vendor to do something very specific to your compiler. 

-------- Original message --------
From: Arcoth notifications@github.com
Date: 08/28/2015 2:26 AM (GMT-08:00)
To: cplusplus/draft draft@noreply.github.com
Cc: sigfpe sig.fpe@axiomatics.org
Subject: Re: [draft] Inconsistent class-key in class template declarations
(#534)

I still don't understand why you think the use of struct or class here in the standard has anything to do with warnings from your compiler.

I don't.

If you get warnings complain to your std::lib vendor, but this is not the right venue.

I was talking about Clang's nonsensical warning that annoyed me, which was the original incentive for opening this issue. I asked a Clang dev above - apparently you're not welcoming OT. I'll ask somewhere else then.

—
Reply to this email directly or view it on GitHub.