Date: Thu, 5 Oct 2023 12:25:09 -0400
On Thu, Oct 5, 2023 at 12:04 PM Niall Douglas via Liaison
<liaison_at_[hidden]> wrote:
>
> On 05/10/2023 16:09, Aaron Ballman via Liaison wrote:
>
> > The syntax that looks like `pre (i >= 0)` is slightly problematic in C
> > in that it's using an unreserved identifier. However, I think that's
> > pretty easy to work around by introducing it as `_Pre` in C and
> > providing something like a `<stdcontracts.h>` with a macro so you can
> > get the `pre` spelling in header code shared between C and C++.
> Surely these can be made context sensitive keywords, so if somebody uses
> `pre` or `post` anywhere else, that's fine? If so, do we really need
> _Pre and _Post?
C doesn't have the notion of context sensitive keywords, so that would
be a novel thing for us. I have no idea how palatable the concept is
to the committee.
> That would leave the people who define preprocessor macros `pre` and
> `post`, but whether on C++ or C++ that would have the same outcomes.
WG14 makes every effort to avoid breaking user code, even when that
code is in macros. C has a reserved identifier namespace that's
different from C++; in C, leading-double-underscore or
underscore-followed-by-capital-letter identifiers are reserved for any
use, whereas in C++ they're reserved "for the implementation". So in
C, we generally make use of reserved identifiers to avoid breaking
users when adding a keyword. (We don't always though -- for example,
we added `typeof` in C23 which is not in the reserved identifier
namespace, but we also could not find any evidence of users using that
identifier, probably because of how ubiquitous the extension is in the
marketplace.)
~Aaron
> Also, for the record, I agree with Aaron that contracts are probably
> even more useful for C than for C++. There is a whole bunch of C which
> would benefit greatly from them.
>
> I also concur that I prefer this syntax to an attributes based one.
>
> Niall
> _______________________________________________
> Liaison mailing list
> Liaison_at_[hidden]
> Subscription: https://lists.isocpp.org/mailman/listinfo.cgi/liaison
> Link to this post: http://lists.isocpp.org/liaison/2023/10/1225.php
<liaison_at_[hidden]> wrote:
>
> On 05/10/2023 16:09, Aaron Ballman via Liaison wrote:
>
> > The syntax that looks like `pre (i >= 0)` is slightly problematic in C
> > in that it's using an unreserved identifier. However, I think that's
> > pretty easy to work around by introducing it as `_Pre` in C and
> > providing something like a `<stdcontracts.h>` with a macro so you can
> > get the `pre` spelling in header code shared between C and C++.
> Surely these can be made context sensitive keywords, so if somebody uses
> `pre` or `post` anywhere else, that's fine? If so, do we really need
> _Pre and _Post?
C doesn't have the notion of context sensitive keywords, so that would
be a novel thing for us. I have no idea how palatable the concept is
to the committee.
> That would leave the people who define preprocessor macros `pre` and
> `post`, but whether on C++ or C++ that would have the same outcomes.
WG14 makes every effort to avoid breaking user code, even when that
code is in macros. C has a reserved identifier namespace that's
different from C++; in C, leading-double-underscore or
underscore-followed-by-capital-letter identifiers are reserved for any
use, whereas in C++ they're reserved "for the implementation". So in
C, we generally make use of reserved identifiers to avoid breaking
users when adding a keyword. (We don't always though -- for example,
we added `typeof` in C23 which is not in the reserved identifier
namespace, but we also could not find any evidence of users using that
identifier, probably because of how ubiquitous the extension is in the
marketplace.)
~Aaron
> Also, for the record, I agree with Aaron that contracts are probably
> even more useful for C than for C++. There is a whole bunch of C which
> would benefit greatly from them.
>
> I also concur that I prefer this syntax to an attributes based one.
>
> Niall
> _______________________________________________
> Liaison mailing list
> Liaison_at_[hidden]
> Subscription: https://lists.isocpp.org/mailman/listinfo.cgi/liaison
> Link to this post: http://lists.isocpp.org/liaison/2023/10/1225.php
Received on 2023-10-05 16:25:24