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.

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!

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.

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