Date: Thu, 5 Oct 2023 12:51:31 -0400
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.
~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
>
>
> 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.
~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
>
Received on 2023-10-05 16:51:47