Yes, that is right.

And for the purpose of this mail thread, that pretty much sums it up.

There are still other concerns that I where I think we don’t have sufficient experience to know that the fature is correct.

As I have said, these are enumerated in other papers, but to just give one example, mapping throws into contract violtions is a dealbreaker for some (and no, you can’t address this in the violation handler because different bodies of code in the program might want different things)

The point being that adding labels, while necessary IMO, is not sufficient to ensure that the feature will meet users expectations.

It is also not clear that labels is the correct or at least the complete solution to the issue. The need to decorate every pre/post/contract_assert seems unnecessarily burdensome.

Thanks,

John.


> On Oct 22, 2025, at 7:16 PM, Herb Sutter <herb.sutter_at_[hidden]> wrote:
>
> John S wrote:
> > That still fails to do what i want, which is to have the library provide know
> > that the semantic they choose will be the one used when the program is linked.
>
> Agreed that this is not directly supported in C++26.
>
> John, just making sure I understand… I think (please correct!):
>
> we agree this will be supported post-C++26 with the labels feature, such as a “contract_assert<enforce>(cond)” or similar syntax to require a specific semantic, and
>
> you think C++26 should not be shipped without a way to express that as part of the first version
>
> … did I get that right?
>
> I just want to make sure I understand your view of this specific concern correctly (and of course I know you have other concerns too, just trying to focus on this one here).
>
> Thanks,
>
> Herb