We're inconsistent about most any combination involving "non". For example, "non-class" appears 18 times and "nonclass" appears 3 times.

Richard, it seems British English prefers the hyphen and US English doesn't. It seems going for "non-whatever" requires fewer changes and often improves readability by highlighting the "non".

Your decision?

List of words appearing without hyphen: nonabstract (1-1), nonclass (3-18), nonconst (1-31), nonconstant (5-9), nondeterministic (2-9), nonempty (5-14), nongraphic (1-0), nonmember (5-53), nonportable (1-2), nontrivial (1-30), nonzero (27-19).

"nonzero" does appear more often than "non-zero", but otherwise hyphens are much more common.

subexpression (37-38)

I don't think a blanket rule for "nonX" vs "non-X" is the right way to go; some "nonX" words are sufficiently common that "non-X" would be a strange choice. Conversely, for terms that we made up, I agree that including the hyphen improves readability, and makes it clearer that the term following the hyphen is indeed our defined term. (I don't want definitions such as "A non-trivial class is a class that is not trivial.")

My current thinking is:

• For technical terms defined by the C++ standard, where "nonX" is either not an English word or not one with the right meaning, use a hyphen: non-abstract, non-class, non-const, non-constant, non-empty (when referring to empty classes), non-member, non-trivial (when referring to special member triviality)
• For plain English words where the "nonX" form is well-established (when the closed form is listed in a common dictionary), do not use a hyphen: nondeterministic, nonempty (when referring to sets), nontrivial (when referring to the difficulty of doing something), and nonzero.
• For plain English words where the "nonX" form is not established, use a hyphen: non-graphic, non-portable.

"Subexpression" should not be hyphenated. (And we should add a definition of it, probably in terms of "immediate subexpression".)

There are also 4 instances of "sub-object" and 5 of "sub-sequence".

Edit: "floating-point" vs. "floating point" looks inconsistent as well.

"Subobject" should not be hyphenated. It's defined without a hyphen in [intro.object]/2.

"floating-point vs. floating point" should use the regular English adjective hyphenation rules, i.e. "floating-point type" (adjective, needs hyphen) vs. "the value has a floating point" (adjective plus noun, no hyphen).

None of the uses seem to be of the adjective plus noun kind like your example. IEEE-754-2008 also does not have a single occurrence of "floating point" without a hyphen.

@zygoloid: Just to clarify, it's a "nonempty sequence" and a "nonempty range" and a "nonempty vector", right? (We don't use "non/empty class often; partly because it's an undefined term and the use of "empty" there was subject to a core issue a few years ago.)

I've added Richard's rules (see bulleted list above) to https://github.com/cplusplus/draft/wiki/Specification-Style-Guidelines .

Still many nonempty & non-empty in WP, even worse: we have both non-empty range & nonempty range, non-empty sequence & nonempty sequence...

I see 5 instances of "nonempty" -- not exactly ground-shaking, but we can definitely fix this.