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
concern?

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.
> >
>