6.11 Future Language Directions

6.11.0 Purpose

This clause records where the language is expected to move, so that programs can avoid constructs whose support may narrow, and so that proposals have somewhere to land.

Nothing here is a commitment to a future edition. Ocean Edition I is a normalization pass rather than the first step of a roadmap, and the strongest possible outcome is that most of this clause stays empty.

6.11.1 Deprecated Constructs

The following are valid in Ocean Edition I and may be removed or restricted in a later edition. An implementation should provide an optional diagnostic for each.

Octal integer constants written with a leading zero.

A leading zero changing the base is a readability trap. A future edition may require an explicit base prefix. Programs should write 0o where an implementation provides it as an extension, or write the decimal value.

Implicit conversion of a signed operand to an unsigned type in arithmetic.

Clause 6.3.1.6 retains the usual arithmetic conversions and clause 6.3.1.7 already fixes comparison. Arithmetic remains the surprising case, and it is diagnosed but valid. A future edition may require an explicit cast.

The comma operator outside a for header.

Its remaining uses are almost always better written as two statements.

Nested block comments left unterminated across a directive.

Already a constraint violation. Listed so that no implementation invents an extension permitting it.

6.11.2 Reserved for the Implementation

Identifiers reserved under clause 6.4.2.1 remain available to implementations. A program that uses them has no guarantee of anything.

The macro prefix __OCEAN is reserved to this specification and to implementation documentation, under clause 6.10.8.2.

6.11.3 Reserved for a Future Edition

The following spellings are not part of Ocean Edition I and shall not be given a meaning by an extension, so that a future edition can use them without breaking existing code:

uninit
module
export
defer
nullptr

Adding any of these would require evidence of a real need, measured against syntax.md section 5, which sets a much higher bar for adding syntax than for tightening semantics, and against the addition test of clause 1.5.1.

import was reserved in earlier drafts of this clause and is now in use. The #import directive of clause 6.10.11 carries the namespace mechanism, and the reasoning that released it is in syntax.md section 5.1. The bare identifier import is not a keyword, since the directive spells it with a leading #, so a program may still use import as an ordinary identifier.

module and export remain reserved. Neither is needed by the namespace mechanism, which controls names rather than visibility or dependency, and reserving them keeps the door open for a future edition that decides otherwise.

nullptr is reserved rather than used. Clause 6.4.4.6 adopts what C23 gives that keyword and spells it null and NULL, so an implementation shall not also provide nullptr as an extension, and a future edition remains free to accept it as a third spelling if interoperation ever makes that worthwhile.

6.11.4 Questions Left Open

These are known gaps rather than plans.

An opt-out from default initialization.

Clause 6.7.9.2 initializes every object, and clause 4.7.1 lets an implementation delete an initialization it can prove is never observed. If real implementation evidence eventually shows a class of programs where the guarantee costs measurable performance that analysis cannot recover, the question of an opt-out spelling can be reopened. Until then the default design is simpler without one. See syntax.md section 29.

A concurrency model.

Clause 5.1.2.4 declines to define one. If a future edition adds threads, it should define a memory model at the same time rather than leaving programmers to infer ordering from volatile.

A bounds-carrying pointer.

The checked profile of clause 4.6.4 detects errors at execution time without changing the language. Whether a source-visible slice type would earn its place is unsettled, and the non-goals of syntax.md section 4 argue against it.

A declared build identity in the language.

Annex K clause K.11.1 requires an implementation to record the translation input closure, and clause K.11.3 requires an artifact digest. Neither is reachable from source. Whether a program should be able to name its own build identity, the way it names __DATE__, is unsettled. A predefined macro would be the obvious spelling, and the argument against it is that the digest of an artifact cannot be known while that artifact is still being produced.

Whole-program type checking across translation units.

Clause 6.9.4 requires diagnosis of what the implementation can detect, which leaves cross-unit mismatch to the quality of the toolchain. A future edition could require type information in object files.

6.11.5 Recommended Extension Subjects

Where an implementation needs a facility this edition does not provide, these subjects are expected, and an implementation providing them should follow the spellings given so that implementations agree with one another.

Each row names the standard the recommended spelling comes from, so that an implementation providing the facility agrees with other implementations rather than inventing a spelling. A recommended extension is not an adoption, and clause 1.4.2 explains the difference.

An extension is bound by clause 4.8, which forbids it from changing anything this specification defines.

Note on static assertions. A translation-time assertion is a genuinely useful facility that ISO C99 lacks, and implementations universally provide one. It is listed as a recommended extension rather than a core feature only because adding syntax requires clearing the bar in syntax.md section 5, and a widely available extension already serves the need.

6.11.6 Library Directions

Future library directions are in 07.02-library-headers.md clause 7.2.26.