The post-Pittsburgh C draft permits assertions without messages

An assertion whose message merely repeats its expression makes the programmer maintain two descriptions of the same condition. The new post-Pittsburgh C working draft, N2310, permits the message to be omitted. The WG14 document log lists the draft on November 11. Its cover identifies the applied proposals and corrections, including Aaron Ballman's work to harmonize static assertions with C++.

Section 6.7.10 now contains a second grammar production for _Static_assert with only a constant expression. The existing form with a string literal remains. When an assertion fails, the diagnostic must include the supplied string when one is present. Omitting the message removes that string requirement without removing the diagnostic requirement.

I like C's ability to express implementation assumptions near the declarations that depend on them. Static assertions are useful for that purpose because the condition is part of compilation. An optional message lets the author reserve prose for information that the expression itself cannot communicate.

The proposal targets a repeated maintenance problem

Ballman's N2265, dated July 6, explains the rationale. The assertion's primary job is to stop translation when a required condition does not hold. Sometimes a separate description adds no information, so requiring one encourages the author to restate the condition in a string.

That string can become another item to update when the expression changes. The problem is particularly visible where an assertion already gives a readable relationship between implementation properties. A message can still explain the larger reason for the requirement, but a string that only duplicates syntax does not supply that reason.

Under the working draft's new grammar, a declaration can express the requirement directly:

/* C2x working-draft syntax, not a C17 guarantee. */
_Static_assert(sizeof(int) >= 4);

The assertion checks an implementation property. On an implementation where the condition holds, the declaration has no effect. If the condition fails, the constraint violation requires a diagnostic. The example makes no claim that every conforming C implementation has the requested integer size, and the comment distinguishes draft syntax from the published C17 language.

The form with a message remains appropriate when the message explains why a requirement exists. An interface might need an implementation property for reasons that its arithmetic expression does not reveal. Optional syntax gives the author that choice without requiring a message whose only content is the same arithmetic written in words.

The earlier C++ discussion considered several alternatives

The history predates this C proposal. Walter E. Brown's N3928, dated February 14, 2014, records the C++ discussion. Existing macros could supply the stringized condition automatically. That approach made one-argument assertions possible without extending the core language, but left the convenience dependent on a wrapper.

Brown's paper records disagreement about what a built-in single-argument form should print. One option was to require the tokens of the expression in the diagnostic. Another was to leave the message to the implementation. Other comments preferred human-language messages or more extensive diagnostic facilities. These were separate choices about the diagnostic contract, even though all started from the same wish to omit a mandatory string.

The direction Brown records from the Issaquah discussion permits a single-argument assertion without requiring token stringization. That matters because the compiler can produce a useful diagnostic without the standard prescribing a preprocessor-style transformation of the expression. The wording adds the shorter grammar form and makes inclusion of a user message conditional on its presence.

N2265 also reports the behavior of several C++ implementations when the message is absent. That observation supports the proposal's usability argument, but the proposed C wording does not require their exact diagnostic text. The portable expectation is that failure receives a diagnostic, with additional user text included when supplied.

Ballman's C proposal follows that limited direction. It does not add a variadic diagnostic facility or a general mechanism for formatting compile-time values. It adds an optional string while keeping the assertion's constant-expression requirement. The small scope is part of what makes the change straightforward to describe and compare across the two languages.

Shared headers motivate compatible syntax

N2265 explicitly identifies combined C and C++ codebases as its audience. A shared header may need to assert a condition that varies between implementations. If one language permits omission of the message while the other requires it, the header author has another syntax difference to account for.

Ballman says the change should require only core-language wording and no change to the static_assert macro in assert.h. He also notes that Clang already implements the form in C as an extension. That existing acceptance is evidence of implementability, but does not make the shorter form portable C17 syntax. The draft's status remains relevant when describing which source a compiler must accept.

The distinction between the keyword spelling and the macro also remains useful. The grammar in N2310 names _Static_assert. Ballman's rationale discusses how the library's familiar spelling can continue to expose the facility. Neither point requires treating the C and C++ language specifications as identical in every detail of constant-expression evaluation.

I consider that kind of harmonization worthwhile when it removes a difference that provides little practical benefit. Shared declarations already need to respect the separate languages' rules. Requiring redundant assertion text does not help explain those rules or the interface's assumptions.

The draft records applied work explicitly

N2310's cover lists the documents applied to the draft, including N2265. Its changed pages use difference marks against the preceding C revision. That provides a direct way to connect the motivating proposal with the resulting grammar and diagnostic wording. A paper's appearance on a meeting agenda alone would not establish the same fact.

The cover also lists corrections involving volatile lvalues, character conversion and other subjects. Their presence does not turn the document into a released compiler feature list. It is a working text against which further standards work can proceed. For static assertions, the concrete result is the added one-argument production and the conditional requirement to include a supplied message in the diagnostic.