A private module fragment would preserve single-file implementation

Moving a class definition a few lines within a module interface should not accidentally change the information available to clients. A simpler semantic-export rule addresses that fragility, but makes it harder to define a type and export it as incomplete from one file. Jeff Snyder and Richard Smith's December 1 proposal, P1242R1, adds an explicit private boundary to reconcile those requirements.

The proposal divides a primary module interface unit into an interface section and an optional inline implementation section. Its placeholder marker is module :private;. That spelling remains proposed syntax in this document. The important change is the boundary's effect on reachability and template context, which is more substantial than organizing declarations under a comment.

C++ codebases already require readers to understand several different mechanisms for hiding implementation. I favor a boundary whose effect survives ordinary source rearrangement. A useful module interface should not depend on a maintainer remembering that one internal type definition must remain below a particular exported declaration.

The earlier export rule depended on declaration order

Richard Smith and David Jones explain the underlying disagreement in their March comparison of module proposals, P0986R0. Under the Modules TS model they describe, exporting a declaration also makes reachable semantic properties available by following relationships from that declaration. The point of export determines which properties are available.

Their example has an exported class referring to a second class. Moving the second class's definition after the export can leave its definition unavailable to clients even though the module itself still compiles. Later exports can introduce conflicting reachable properties. A change that appears to reorganize source can therefore alter the module's interface.

The alternative Atom rule separates name visibility from the semantic properties available from an imported interface. Export controls which names are visible, while the interface unit supplies its semantic effects without relying on the same declaration-order distinction. The comparison argues that this is more robust under refactoring.

That rule has a cost for a one-file interface. Defining a type later in the same interface unit no longer supplies the old technique for keeping its completeness private. A distinct implementation partition can preserve the boundary, but requires another source file. P1242R1 explicitly identifies this tension as its motivation.

The private fragment creates a boundary within the file

The proposal allows an inline module implementation partition after the interface section. Its example expresses the intended structure compactly:

// Proposed single-file module structure in P1242R1.
export module storage;
struct state;
export using state_pointer = state*;

module :private;
struct state {};

The interface introduces the incomplete type and exports a pointer alias. The definition belongs to the private section. This preserves the example's intended external knowledge without relying on the definition's position relative to an individual export inside one undivided interface.

The definition still belongs to the module's implementation. The proposal describes the private section as being imported alongside the corresponding primary interface section when that section is imported into the module's implementation context. Keeping the two sections in one source file therefore does not make them semantically indistinguishable.

P1242R1 limits the private fragment to a primary module interface unit. Its proposed wording also prohibits export declarations inside that fragment. The marker consequently changes what a declaration may do, rather than merely suggesting that readers should regard the following declarations as internal.

Templates and inline definitions need precise treatment

The wording requires an exported inline function or variable to be defined outside the private fragment in the translation unit containing its exported declaration. This is a meaningful limit on how much implementation the fragment can hide. The facility does not promise that every definition needed by consumers can be relocated below the marker.

Template rules also distinguish the interface section's end from the end of the complete file. P1242R1 changes relevant points of instantiation and reachability wording to account for whether a declaration occurs before or within the private fragment. Those changes prevent the additional source section from silently enlarging the interface context available to importers.

I find that part of the proposal necessary to its argument. A one-file feature would be incomplete if it only specified where authors may write declarations. It also needs to specify which declarations template processing can consider, because deferred lookup can otherwise expose implementation details through a different route.

The paper presents several alternative marker spellings and explains why its placeholder resembles a module implementation partition while remaining easy for tools to recognize. Syntax remains an open choice in this revision. Using a keyword for the partition-like name avoids conflict with ordinary partition names, and omitting the repeated module name avoids restating information already established at the start of the file. These are reasons for the placeholder, without making it a settled language spelling. The concrete design is an explicit interface boundary within one primary file, with separate reachability rules for the implementation section and restrictions on exported inline definitions.