N2775 proposes literals that preserve bit-precise arithmetic

A literal 2 can change the arithmetic type of an entire expression. That is an awkward property when the surrounding operands use bit-precise integer types to constrain the computation's width. Avoiding ordinary integer promotions for those types solves only part of the problem. An ordinary literal still participates in the usual arithmetic conversions and can make int the common type.

N2775 proposes literal suffixes for that remaining case. Aaron Ballman and Melanie Blower propose wb for signed bit-precise constants and uwb for unsigned ones. The WG14 document log lists the paper on July 26, while the document itself is dated July 13. The suffixes remain a proposal at this point.

I find this a useful example of how a small language addition needs expression-level consistency. A type can describe a precise intent at its declaration and still lose that intent when combined with an ordinary constant. Making the constant's type explicit is a direct way to preserve the intended arithmetic rules without filling an expression with casts.

The common type changes the operation

The paper considers a function taking two _BitInt(7) values and computing an expression equivalent to left + right * 2. The ordinary literal has type int. Because that type has greater width, multiplication converts the narrow operand to int. The subsequent addition also uses the wider common type, and returning the result converts it back to the function's bit-precise return type.

The final conversion does not undo the fact that the intermediate operations had a wider type. For the hardware-oriented uses motivating bit-precise integers, that matters. The purpose of the suffix is to give the constant a type in the same family, so ordinary conversions do not introduce int simply because a small constant appears in the source. A cast can already express that intention, but repeated casts make expressions longer and obscure the calculation being described.

An illustrative expression under the proposed syntax is:

_BitInt(7) scale_and_add(_BitInt(7) left, _BitInt(7) right)
{
    return left + right * 2wb;
}

This is proposed C syntax, not a portable C17 function. It also does not prove that every input produces a representable signed result. The suffix controls the literal's type and therefore the conversions. It does not introduce saturation or range checking. An algorithm requiring a wider result still needs to select an appropriately wider operation.

The literal determines the minimum width

The proposed signed suffix chooses the smallest width greater than one that accommodates the literal's value and a sign bit. The unsigned suffix chooses the smallest width greater than zero that accommodates its value. Consequently, 3wb has proposed type _BitInt(3), while 3uwb has proposed type unsigned _BitInt(2).

Hexadecimal notation does not remove the signed suffix's sign-bit requirement. The paper gives 0x3wb the same signed width as 3wb. This makes the suffix's meaning consistent across the base used to spell the value. A reader can identify signedness from the suffix without reconstructing a different candidate-type rule for hexadecimal constants.

A leading minus remains an operator applied to the constant. The proposal describes -3wb as a signed three-bit value followed by negation. In -3uwb, the constant first has an unsigned two-bit type and negation then wraps in that type. This is a substantive semantic difference despite the small textual difference between the suffixes.

The wording permits wb and WB, but excludes mixed spellings such as Wb. It allows the unsigned marker in combination with that suffix. This follows the proposal's explicit grammar rather than a general assumption that suffix letters can always be rearranged or mixed in case.

Spelling has lexical constraints

An earlier version of the broader integer proposal used xi and uxi, reflecting the former _ExtInt type name. Renaming the type to _BitInt made those spellings less appropriate. The paper also identifies ambiguity around hexadecimal notation as a reason to reconsider them.

The seemingly natural bi alternative conflicts with existing literal syntax. The authors use 0x3bi as an example of a valid imaginary literal whose hexadecimal value includes the b. A suffix design has to preserve tokenization rules as well as suggest a memorable name. The chosen wb spelling draws on the specific-width length-modifier work cited by the proposal.

I prefer to evaluate the suffix by those constraints and its conversion behavior. A short spelling is useful only if it can coexist with existing source and gives the intended constant a predictable type. N2775 makes both questions explicit in its rationale and proposed grammar.

The preprocessor introduces another boundary. A bit-precise constant too large for the supported intmax_t or uintmax_t range cannot appear in a #if controlling expression under the rules described in the paper. It can still be a valid constant in an ordinary expression or initialization. Using the same macro in both places therefore requires attention to the preprocessor's separate evaluation limits.