Am Dienstag, den 21.09.2021, 10:06 -0700 schrieb Ryan McDougall:
> 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

You mean that a compiler should not be allowed to ignore it
when in "enforcing" mode and that a compiler that does not
support this feature should fail during compilation? Correct?

Why is the later important for 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?

I am just trying to understand the design.

> What is the problem that is created by this confusion?

Confusion tends to cause problems - especially in
programming. But I am not sure there is a serious
problem.

Generally, I think it would just be nice if we have clear
guidelines such as "an attribute can always be removed
without changing the semantics of a well-defined program".
And when we have such guidelines, then it would also be
nice that the syntax clearly differentiates between
attributes and other features that follow other rules.

But maybe also the guideline can be adapted, so I am
not entirely sure there is a problem.

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

(or more precisely: When used as intended, the meaning
of a correct program is not changed by adding contracts.)

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

I just point out that attributes can be added to an
existing code base easily (because unknown attributes
can be ignored by compilers), while this feature
- as proposed - needs to be protected with #ifdefs
whenever the code still needs to be able to be
compiled by older compilers (which is common).

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

If this is a benefit, shouldn't we use attribute syntax
which would then guarantee this property?

> 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 far, I am OK with the syntax. I am just trying to
understand the design, because I am still a bit confused
about some of the explanations.

Martin

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