I don't think we want to use code font for the arithmetic operators, as that implies the C++ expression x + y which is not performed in infinite precision. For unsigned types with width no less than int the result of x + y always fits in T, by definition.

@jensmaurer, the paper doesn't use code font for anything here, not even the type T. What was the intended presentation for the standard?

We definitely want the computation to be in the math domain, otherwise "is representable" doesn't make sense.
x and y are parameters, so (individually) need to be monospace, I think.

I thought it was fine due to the first paragraph.
But turns out it's a note.

[ Note: In the following descriptions, an arithmetic operation is performed as a mathematical operation with infinite range and then it is determined whether the mathematical result fits into the result type. ]

Can we make the note not be a note? It seems necessary for the understanding of the text. Then, we can spell this as `$\tcode{x} + \tcode{y}$, that'd be close enough I think.

There are other situations where we use math arithmetic and then map back to C++. For example, most prominently, in [expr.pre] p4 to determine when a result is undefined. But, if you feel the note needs to be normative, go for it.

I think with the formatting changes, we can just about leave it as is. It should perhaps be for LWG to decide whether the specification is sufficiently clear here. @jwakely Should I create an LWG issue for this, or just an informal mail to the reflector maybe?

Just an email is fine, I think.