C++ Logo


Advanced search

Re: [wg14/wg21 liaison] [isocpp-sg21] Telecon to review P2388R1 Minimum Contract Support: either Ignore or Check_and_abort

From: Ryan McDougall <mcdougall.ryan_at_[hidden]>
Date: Tue, 21 Sep 2021 10:06:56 -0700
On Tue, Sep 21, 2021 at 9:56 AM Uecker, Martin <
Martin.Uecker_at_[hidden]> wrote:

> Am Dienstag, den 21.09.2021, 09:25 -0700 schrieb Ryan McDougall via
> Liaison:
> > > I mentioned earlier in the thread how they indicated their
> > > implementations were going to work (eat tokens between [[ and ]]
> > > with
> > > a generic diagnostic), and the syntax used for contracts would
> > > cause a
> > > problem for that sort of implementation strategy. So I'm raising
> > > that
> > > issue because I'm concerned that the non-ignorable nature of this
> > > attribute-like syntax is going to generate pushback, as happened
> > > during C++20. I can try to go into more detail of how I understood
> > > the
> > > implementer's concerns, but I don't think that needs relitigation.
> > > The
> > > concerns were sufficient to cause WG14 to request changes to the
> > > proposal and so I think we should trust the concerns are valid.
> >
> > I'm unclear what the reservation is. With the C++20 syntax (re-used
> > here), that same implementer could not "eat tokens between [[ and ]]"
> > -- but would instead need to "check if there's a colon, and then eat
> > tokens between [[ and ]]". I'm not sure that's a high burden.
> I agree it is extremely easy to implement.
> But the design goal is not entirely clear to me: Either you
> want it to be ignorable (and this is not just about compilers,
> but also about human readers), then it should be an attribute.

It should *not* be ignorable in my opinion, because ignoring runs counter
to the purpose of the feature -- I'm only pointing out that ignorability
does not affect semantics.

> Or you don't want it to be ignorable, then it should be
> completely different syntax that can not be confused by
> an attribute by a human reader!

So then human confusion, not changed semantics when ignoring, is the

What is the problem that is created by this confusion?

> It is not quite clear to me what it is.
> Your above explanation says it can be ignored, because it
> will not change the meaning of a correct program.
> This makes sense and then it should be an attribute.
> Introducing new syntax breaks existing parsers,
> preventing use of this feature in projects that still
> need to be compiled on older compilers. This seems
> counterproductive if we like to see these annotations
> added to projects as soon as possible.

It is the norm, not the exception, that new code cannot work in old
compilers. I'm not sure what the objection is.

With the C++20 syntax any old compiler would actually work just fine if
they work by ignoring everything between [[ and ]]. That's a benefit.

And what is the alternative syntax you're proposing that works better? I
think the correct way to proceed is to submit your syntax to SG21 asap so
we have a hope of releasing for C++23.

> So the choice of syntax does not make any sense to me.
> (or at least the explanations)
> It would make sense to me to introduce a new generic
> type of attributes that requires syntax checking even
> if the attribute is not supported by a compiler. This
> is an excellent idea! But then it makes no sense to
> introduce this new syntax just for three special
> contract features, because the whole point of such
> syntax would be to get syntax checking also for
> unknown (e.g. from others vendors) or new and
> not yet supported features.
> Martin
> >
> > If that implementer either doesn't want to support contracts, or for
> > performance reasons on their platform cannot, then correct programs
> > will still be correct programs -- just incorrect programs will have
> > one less diagnostic tool for discovering bugs. A non-compliant
> > implementation is perfectly workable.
> >

Received on 2021-09-21 12:07:09