alt Hacker NewsI see. Somehow I missed that paper. I've seen it referred to, but never in a form where I could find it.
And now I'm even more confused. Why is this so critical that we can't say we're going to put it in another next version of the standard? Compile is regularly see things in the future version of standards and them implement early. I'm not disagreeing with the paper. I'm disagreeing that this is so critical it needs to abort the whole process.
Replies
I was in the same boat as you with respect to that paper. I only know its number because Herb mentioned it.
The only red-string-on-a-cork-board I can connect is between guaranteed enforcement and the design decision that "contract assertions must not be used for error handling and input validation". The latter would seem to rule out guaranteed enforcement now and in the future and EWG apparently voted against P3911 back in January [0], so perhaps they think that they won't ever see guaranteed enforcement if contracts is left in the standard as-is.
That's all quite speculative, though, so take that with an appropriately-sized grain of salt/
[0]: https://github.com/cplusplus/papers/issues/2536#:~:text=Dire...
> Why is this so critical that we can't say we're going to put it in another next version of the standard?
This feature was first proposed in 2004. In 2018, they were added to the draft of the standard, and then removed in 2019. So that already has been happening, for over a decade.
Part of the reason this is coming to a head is that it's already been a long time. Another reason is that some see contracts as fitting into the safety story for C++. Part of it is because, well, standards are done by the people that show up, and the people who show up care about this.
> I'm disagreeing that this is so critical it needs to abort the whole process.
It's a byproduct of how the process works. There are a series of votes, and they're not done by the same people. Some people voted yes to put them in, and then the vote after involved people voting no, they don't think they're good enough to put in. It is not so much that "this is so critical that it needs to abort the whole process," so much as it is "the final vote is the time when those people get to express their support or dissent." One of the proposals in the paper is that they could remove this feature, and then the rest would likely move forward. It will only hold up the entire thing if the people who are pro this feature landing decide that it's worth holding everything else up for.