@jwakely: Looks like your area.

TrivialClock is similar, and it's always in code font. A global decision about what to do with these would be useful.

On the other hand, "Clock" in "Clock requirements" appears in normal font most of the time but in code font once.

Named sets of requirements are usually formatted in code font. See [utility.requirements] for a bunch of examples, in addition to TrivialClock. UnaryTypeTrait, BinaryTypeTrait, and TransformationTrait are outliers here.

I would be fine with having a different typographical convention for them, but it should be applied consistently.

I'll update this PR to change them to code font for consistency tomorrow.

I agree these concept-ish terms should all be typographically distinct, and currently we do that with code font.

I think the one occurrence of "Clock" in code font is wrong, IMHO "Clock requirements" is more like "Associative container requirements" than a concept like "CopyConstructible". (Although it could be argued the other way, Lockable and TimedLockable are counterexamples.)

As #1154 says, BaseCharacteristic probably shouldn't be one of these terms, so don't change that.

And then there's "Allocator requirements" which is sometimes code font and sometimes not.

I'm not sure if the \defn instances should have \tcode inside them, too.

@jwakely: Are you waiting for some changes from the author here?

Can you please rebase this? I think we're ready to apply this.

Rebased. "Allocator requirements" and some others are still inconsistent like pointed out by @jwakely, but I don't have time to look into them at the moment. I think they can be done in a separate PR.