Am Donnerstag, dem 05.10.2023 um 12:51 -0400 schrieb Aaron Ballman:
> On Thu, Oct 5, 2023 at 12:45 PM Martin Uecker <ma.uecker_at_[hidden]> wrote:
> >
> > Am Donnerstag, dem 05.10.2023 um 12:25 -0400 schrieb Aaron Ballman via Liaison:
> > > 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.
> >
> > Can we just make these attributes? Then it does not have to be a
> > keyword and we get the __pre__ and __post__ versions automatically.
>
> WG21 does not want contract annotations to be ignorable in the same
> way as attributes (both in terms of allowing an implementation to not
> support contracts and in terms of not allowing syntactic errors in the
> arguments to the contract), so that would be a very poor fit.

Ah, right, I forgot that this was a design goal.

(The problem is that this will make it much harder for C projects
to usefully adopt it.)

Martin
 

>
> ~Aaron
>
> >
> > Martin
> >
> >
> > >
> > > > 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 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/1226.php
> >