Oh great, another contracts paper. We're at P4005 now? The paper numbers alone tell you how many trees have died for this feature.

It is ill-formed to mix guaranteed-enforced assertions and P2900 assertions in the same function declaration. That is the most future-compatible approach given the C++26 time frame.

I've been following contracts since SG21 was chartered, and this paper crystallizes the fundamental strategic question the committee has been dancing around:

1. P2900 ships in C++26 with configurable semantics (ignore/observe/enforce/quick_enforce)
2. There is clear demand for a "guaranteed, cannot be ignored" tier (see P3919R0)
3. P3911 solves this by adding always-enforced variants to P2900's existing syntax
4. P4005 solves this by creating an entirely separate keyword vocabulary

The "ill-formed to mix" rule isn't a limitation - it's a thesis statement. Voutilainen is arguing that guaranteed enforcement is sufficiently different from P2900's model that it needs its own design space.

But this means your codebase has two contract dialects. Your tools need to understand both. Your developers need to know when to use pre vs entry_cond. This is not composition - it's fragmentation.

Meanwhile Rust has had this since 1.0 with zero committee meetings. But sure, let's debate the spelling of "your function must not receive garbage" for another decade.

the selection mechanism for which evaluation semantic is used for any such guaranteed-enforced assertion is implementation-defined

So let me get this straight. The paper is called "guaranteed-(quick-)enforced contracts." The word "guaranteed" is in the title. The entire pitch is "unlike P2900, these can never be ignored or observed." And then, buried in the semantics section, we find that whether you get enforce (calls your violation handler before termination) or quick_enforce (just terminates, no handler) is... implementation-defined.

That's not a minor detail. The violation handler is the mechanism by which production systems do logging, telemetry, graceful shutdown. If the implementation can choose quick_enforce by default and your handler never runs, you've guaranteed enforcement of the check but not guaranteed that your code gets to react to the failure.

This is still meaningfully stronger than P2900's model where ignore is a valid semantic. I won't pretend otherwise. But "guaranteed enforcement" and "guaranteed your handler runs" are different claims, and the paper title sells both.

Edit: To be fair, P2900's quick_enforce has the same property. The difference is that P4005 can never fall back to ignore, which is the real safety guarantee. The handler issue is orthogonal. I'm nitpicking the marketing, not the mechanism.

The mangling suggestion is the most interesting part of this paper, and I suspect most people will skip right past it.

The idea: if entry_cond(x >= 0) is mangled into the function's symbol name, then changing the condition to entry_cond(x > 0) changes the mangled name. Any translation unit compiled against the old declaration gets a linker error instead of a silent behavioral change.

This is the paper's answer to the cross-TU consistency problem that P2900 punts to the build system. If your contract changes, you must recompile everything that calls the function. The linker enforces this mechanically.

Two concerns though:

1. Mangling arbitrary expressions is not trivial. GCC already does this for concept constraints, but contract predicates can be significantly more complex than concept requirements.

2. This is marked as QoI (quality of implementation), not normative. An implementation that doesn't mangle - and therefore doesn't detect stale callers - is conforming. That undermines the safety story.

entry_cond? return_cond? Who named these, a Java developer?

I thought we were going with pre/post/assert like normal people.

The "no constification" decision is doing a lot of heavy lifting here. In P2900, contract predicates undergo a const transformation - the predicate is evaluated as-if the parameters were const. This paper explicitly rejects that.

Which means:

bool log_and_check(int x) {
    std::clog << "checking: " << x << "\n";
    return x >= 0;
}
void f(int x) entry_cond(log_and_check(x));

This is legal, and the logging side effect happens on every call. Under P2900 with constification, you'd need const-callable stream operations for the same thing.

I concede this is more flexible. But it means contract predicates become a side-channel for arbitrary computation, and "guaranteed enforcement" means "this code definitely runs on every call, including through function pointers." That's a lot of power and a lot of surface area for misuse.

I don't even care about the technical details anymore. Contracts have been "almost done" since 2018. P0542, P2388, P2900, now P3911 and P4005. At what point do we admit the committee is structurally incapable of shipping a contract facility without immediately needing a sequel?

Did anyone else notice this paper says absolutely nothing about virtual functions?

The paper says entry_cond is checked "whenever a function is called" and emphasizes "Not Even for Indirect Calls." Great. But what about:

struct Base {
    virtual void f(int x) entry_cond(x >= 0);
};
struct Derived : Base {
    void f(int x) entry_cond(x >= -10) override;
};

Which entry_cond applies when you call through a Base*? Liskov says the derived class can weaken preconditions. But "guaranteed enforcement" suggests the declared condition must always hold. These are in tension and the paper doesn't address it.

P3911 at least acknowledges the inheritance question.

committee gonna committee

The full form of this proposal hasn't been implemented yet. All the constituent bits have been

In embedded we call this "we've tested all the components individually but never powered on the assembled board." The integration is where the surprises live.

I don't doubt that always-enforced assertions exist (every assert in release mode is one). I don't doubt that expression mangling works (concepts proved that). But the combination of guaranteed enforcement + new ODR rules + no constification + exception passthrough + mangled signatures is a system, and systems have emergent behavior that unit testing the parts doesn't reveal.

For what it's worth, in my domain (bare-metal ARM) I want guaranteed enforcement badly. We can't afford the "maybe the assertion is compiled out" lottery that GSL's Expects gives us in release builds. But I want to see a prototype before we commit to keywords that can never be un-added.

Can someone please just ship networking before we finish contracts season 4?

mandatory_assert sounds like what I tell myself every morning about going to the gym. Guaranteed enforcement. Never ignored. Still doesn't happen.

No formal wording though? Just "pseudo-specification"? For an EWG paper?

Just realized we now have P2900 (configurable contracts), P3911 (non-ignorable contracts within P2900), and P4005 (non-ignorable contracts outside P2900). Three proposals solving the same problem with different tradeoffs. EWG is going to love this.