The C23 charter makes compatibility a design constraint

A language committee needs a basis for rejecting an attractive feature as well as accepting one. The C23 charter in N2611, dated November 9 and authored by convener David Keaton, describes principles for making those decisions. Its subject is the revision process. It does not establish a catalogue of technical changes that the next standard must contain.

The WG14 document log records the revised charter alongside a separate proposed schedule. Together they address two different constraints. The charter describes the kinds of justification a change needs, while the schedule gives the revision a bounded process.

C was my first language, and its small conceptual core remains part of what I value. A revision has to account for the large amount of code whose meaning already depends on that core. The charter is useful because it makes that obligation part of the discussion before individual proposals compete for inclusion.

Existing source constrains a new rule

The charter's inherited principles give existing code a strong claim on compatibility. They also distinguish existing source from existing implementations. A standard can require implementations to change while trying to preserve the meaning of programs that depend on the language.

That distinction matters when evaluating prior behavior. One compiler's acceptance of a construct does not, by itself, establish the rule every implementation should adopt. Conversely, the fact that a rule would be convenient to implement does not establish that it preserves valuable existing source.

A proposed change therefore needs to identify what happens to programs already written. A new diagnostic and a silent behavioral change have different consequences. The former makes the disagreement visible during compilation. The latter can leave a program apparently successful while changing its result.

This provides a practical way to read a proposal. The explanation should show an existing program and the interpretation it receives before and after the change. Without that comparison, a general compatibility claim can hide the precise construct whose meaning is at issue.

The same reasoning applies to source shared among several environments. A change that fixes one implementation's inconvenience may create a new difference for another. The standard's task includes explaining which common agreement the change establishes.

Prior practice supplies evidence

The charter carries principles about standardizing established practice and avoiding unsupported invention. It also asks proposals to supply prior art and implementation history. That makes evidence part of the submission, alongside the desired semantics.

Prior practice can answer questions that a small example leaves open. It can show how users spell the operation in larger programs and what implementers found difficult. It can also identify compatibility problems that were invisible in an isolated language sketch.

Evidence of use does not make every existing design ideal. A widely used extension can still have ambiguous behavior or an awkward interaction with another feature. Standardization needs to decide whether to preserve that behavior, clarify it, or request a different design.

There is a corresponding risk in standardizing only an attractive abstraction. If no implementation has exercised its interaction with the rest of the language, the specification may be committing users and implementers to unresolved details. Requiring implementation evidence makes those details part of the decision.

I see this as particularly appropriate for C's interoperation role. A new spelling can become an agreement among compilers and foreign-language callers. Evidence about representation and use is relevant before that agreement becomes something other software must preserve.

Simplicity needs a definition

A short feature can add a large conceptual requirement. Its syntax may occupy one line, while its interaction with conversions or lifetime rules requires a new account of many existing expressions. Counting keywords is therefore an incomplete measure of language complexity.

The charter's concern with conceptual simplicity gives a more useful question. How many new ideas does a programmer need to understand the operation correctly? A design that reuses a familiar concept can be simpler to explain, even when its formal wording is substantial.

The opposite can also occur. Reusing an existing spelling for a new meaning can make a feature appear compact while increasing ambiguity for readers. A compatibility argument needs to consider that reading cost as well as whether an old program still compiles.

This is relevant to library interfaces too. An interface can require information in a form that makes its relationships explicit. If a count describes an array, placing the declarations so the relationship can be expressed helps both readers and tools. The source then carries more of the contract that otherwise needs a separate explanation.

That goal still involves tradeoffs. An interface might have an established parameter order that callers already depend on. Improving its descriptive form does not erase the migration cost. A proposal needs to explain why the resulting contract justifies that cost.

A schedule changes the unit of decision

A bounded revision cannot accept every useful idea at once. The proposed schedule separates proposal work from draft preparation and ballot-related stages. That organization gives technical discussion a point at which it must produce text suitable for the next step.

The practical implication is that a promising idea and a ready proposal are different states. The latter needs enough specification and evidence for others to assess it. A schedule can make unfinished interactions visible because there is a defined period for resolving them.

This also gives implementers and users a more precise way to interpret committee activity. Discussion establishes that a topic is under consideration. A revision plan establishes when the process intends to consolidate its work. Neither statement establishes that a particular feature is already available in a compiler.

N2611 makes the evaluation criteria visible before those individual outcomes. Compatibility requires an account of existing source, and conceptual simplicity requires an explanation that can be taught. A proposal that meets those obligations gives the committee something concrete to judge within the revision's scheduled stages.