The subclause also has a weird way of spelling "cv".

Wait. I believe we agreed in #1139 that type placeholders such as "let T be decay_t<U>" should be formatted with \tcode, except that an index is suffixed using math mode.

Why do you believe this section should use \placeholders? (I agree this is slightly, but only slightly, different because we have an implied meta-iteration over the set of all matching types, so you can't just imagine a typedef there.)

Agreed on the "cv" part.

@jensmaurer: I see. To be clear, I'm not taking a position here whether the gadgets in question should be normal types or placeholder types. What I meant is that if they are placeholder types, then they should be formatted as I described. If we don't actually want to style them as placeholders at all, then we should of course apply a different resolution, but I hadn't thought of that.

Uh, second thoughts about the "cv" part: We also have "VQ" in this section, meaning just a volatile qualifier (or nothing). We don't have a notation similar to "cv" for this case in 3.9.3 [basic.type.qualifier]. There's something to be said about internal consistency in [over.built], too.

Yeah, absolutely. And that was somehow my motivation for this issue: It's not even internally consistent at the moment.

I have no problem keeping most of this as is, I just think we can clean it up locally.

As for the CV/VQ bit, maybe we can have some lower-case construction like "vq_n" to mimic the usual styling for "cv"? I'm open to suggestions.

Ok, let's go with \placeholder for the moment in this section. After all, the implied "for-all" quantification make the T's more like meta-variables than specific types.

Yes, I agree, this isn't "one particular type T", but instead a "for any type T", so I don't see a contradiction between the meta variable here and #1139.