The Integer Sets proposal separates bool from unsigned integers
N3727 reorganizes C's integer type categories and proposes signed one-bit integers. The work changes the meaning of categories used throughout the specification.
Calling bool an unsigned integer type creates a mismatch between a category name and the operations that readers associate with it. A Boolean conversion asks whether a value is zero. It does not behave like reducing an arbitrary integer modulo the number of values representable by an ordinary unsigned type. Robert C. Seacord's Integer Sets proposal reorganizes those categories so that their names better match their intended use.
The fourth revision, N3727, carries an October 3 revision date and change-log entry. Its title concerns sets of integer types in the specification. It does not introduce a general language facility for declaring sets of integer values. The WG14 document log lists it among the continuing proposals for C.
That distinction is material to the proposal's scope. The work changes which types belong to terms used throughout the standard, then repairs clauses that relied on the previous grouping. Some edits preserve existing requirements under the new classification. Others deliberately change what the draft language would permit.
Boolean conversion is a poor fit for modulo intuition
N3727 contrasts C's classification with C++. In the C wording it discusses, bool belongs among the standard unsigned integer types. C++ treats it separately. Seacord argues that the C grouping is confusing for users and implementers because the Boolean type has special conversion behavior.
The paper gives (bool)4 as an example. Its result is one. Treating Boolean conversion as ordinary one-bit unsigned reduction would suggest zero instead. The proposal does not need to change that conversion to fix the mismatch. It changes the taxonomy that encouraged the wrong inference.
C was my first language, and knowing where an apparently simple rule stops applying is much of the work of writing it well. A category that repeatedly requires an exception for bool makes that task harder. I prefer the proposal's effort to state the distinct case directly, provided the dependent wording preserves the intended interfaces.
N3727 removes bool from the unsigned integer and standard unsigned integer categories. It retains the type within the broader integer and basic-type categories. This is not a proposal to make Boolean values unrelated to integer operations. It is a more specific change to the names that clauses use when they mean ordinary unsigned arithmetic.
Category changes propagate through library wording
Moving a type between categories can change a requirement without changing the sentence that contains it. N3727 uses the width and maximum macros as an example. A rule phrased for all unsigned integer types would cease to include bool after the proposed reclassification. Preserving BOOL_MAX therefore requires an explicit mention of the Boolean type.
The paper proposes that explicit wording for compatibility. Its discussion distinguishes conceptual reservations about a maximum macro for a Boolean from the practical decision to retain it. A taxonomy cleanup still has to account for existing source interfaces that use the old categories indirectly.
The bit-manipulation functions provide another case. Existing wording repeatedly excludes bool from groups of unsigned input types. Once the type is outside that group, the exclusion becomes unnecessary. The draft shows edits across leading-bit and trailing-bit operations as well as rotations. Those edits are consequences of a shared definition, rather than unrelated new algorithms for every function.
Not every occurrence needs a semantic repair. The paper discusses a return-type requirement for counting leading zeros where bool could not represent the required result anyway. Removing it from the unsigned category does not change that result requirement. This kind of distinction is why the proposal has to examine individual uses instead of replacing a phrase mechanically throughout the document.
A signed one-bit type has a use
The proposal also permits _BitInt(1) as a signed bit-precise type. In the described two's-complement model, its values are zero and minus one. That gives it a useful role different from an unsigned one-bit value with values zero and one.
N3727 motivates the case with decomposition of a wide signed multiplication for FPGA hardware. Separating an input's most-significant bit from the remaining bits needs the high component to contribute a negative weight when set. A signed one-bit component can describe that contribution. The proposal consequently connects a small type-system boundary to an actual arithmetic representation problem.
This remains proposed wording, not a claim that C23 implementations already accept signed _BitInt(1). Its significance is that the unsigned one-bit case no longer needs to remain an isolated exception in the relation between signed and unsigned bit-precise types. The revision organizes that relation alongside the separate treatment of bool.
For readers of the standard, the immediate issue is how much meaning a category name carries. N3727 changes that meaning and enumerates dependent edits so that requirements remain deliberate. A reference to unsigned integer types should identify the types whose arithmetic and representation rules the surrounding clause intends to use.