Date: Thu, 5 Oct 2023 12:48:09 -0400
---- (With my chair hat OFF) ----
I greatly prefer the syntax of P2961R1. It is superior in every way and
does not imply ignorability, no r does it contain the syntax-level
ignorability that Aaron pointed out is still in C for C23. We have a myriad
of ways to fudge the keyword spelling if necessary for C and C++ interop,
such as _Pre/__pre__, _Post/__post__, and other syntax tricks we can pull.
However, I don't really have an appetite to actually put Contracts into C
myself; I'd let someone else take up that mantle if the C++ experiment
proves to be successful.
---- (With my chair hat ON) ----
If you'd like to get SG22's opinion Officially™, you are more than welcome
to say this is important enough to invite a review by SG22. If you picked
the [[ ]] attribute syntax it would be more important for SG22 to review it
and give feedback (And at that point I would *insist* upon a review and
feedback), but if not and the syntax is in a novel location I don't see how
we'd need explicit cooperation. (E.g., when C++11 got static_assert(…), we
just handled the syntax difference by having _Static_assert(...) in C and
piling an extra keyword in <assert.h>.) Same process that Aaron mentioned
before: ugly keyword first, normal keyword later. Nothing either Committee
can't handle.
Sincerely,
JeanHeyd
I greatly prefer the syntax of P2961R1. It is superior in every way and
does not imply ignorability, no r does it contain the syntax-level
ignorability that Aaron pointed out is still in C for C23. We have a myriad
of ways to fudge the keyword spelling if necessary for C and C++ interop,
such as _Pre/__pre__, _Post/__post__, and other syntax tricks we can pull.
However, I don't really have an appetite to actually put Contracts into C
myself; I'd let someone else take up that mantle if the C++ experiment
proves to be successful.
---- (With my chair hat ON) ----
If you'd like to get SG22's opinion Officially™, you are more than welcome
to say this is important enough to invite a review by SG22. If you picked
the [[ ]] attribute syntax it would be more important for SG22 to review it
and give feedback (And at that point I would *insist* upon a review and
feedback), but if not and the syntax is in a novel location I don't see how
we'd need explicit cooperation. (E.g., when C++11 got static_assert(…), we
just handled the syntax difference by having _Static_assert(...) in C and
piling an extra keyword in <assert.h>.) Same process that Aaron mentioned
before: ugly keyword first, normal keyword later. Nothing either Committee
can't handle.
Sincerely,
JeanHeyd
Received on 2023-10-05 16:48:28