On 20/09/2021 22.49, Aaron Ballman via Liaison wrote:
> On Mon, Sep 20, 2021 at 12:36 PM Ryan McDougall
> <mcdougall.ryan_at_[hidden]> wrote:
>>
>> Can you help me understand the concern here -- is it that C will have to update its grammar to recognize this syntax as not ignorable, and they would rather not?
>
> I am raising a concern as a liaison with WG14 who was the one that
> standardized [[]] syntax in that committee. During those discussions,
> we had a *lot* of debate over the syntax and the semantics of the
> feature, but one of the concerns that was raised by an implementer was
> their requirement that attributes be "ignorable" as they are in C++.
> They have implementation burdens with nonignorable attributes for some
> of their implementations and they very much appreciated the discussion
> in WG21 N2761 about the design intent of when it's appropriate to use
> an attribute vs other syntax. To save people effort, a key point from
> that paper was:
>
> "After the meeting in Toronto, we added specific guidance on the
> choice of when to use an attribute to avoid misuse. There was general
> agreement that attributes should not affect the type system, and not
> change the meaning of a program regardless of whether the attribute is
> there or not."

The key confusion here is that the proposed contract facility
is, in fact, NOT expressed via attributes. The general attributes
grammar does not permit the sequence of tokens that the contract
facility uses inside [[ ]].

> The current proposal changes the meaning of code when the contract
> attribute is not present. Further, that document gives some advice on
> when it's reasonable to use an attribute vs another syntax, and one
> explicit point on when to not use an attribute is "The feature is a
> central part of the declaration that significantly affects its
> requirements/semantics" and the whole point to contracts is to
> significantly affect the requirements of a call.

Right, that's part of the reason why contracts are not expressed
via attributes to begin with, although both share the use of [[
and ]] delimiters.

> I mentioned earlier in the thread how they indicated their
> implementations were going to work (eat tokens between [[ and ]] with
> a generic diagnostic),

Not checking the top-level syntax within [[ ]] seems borderline
conforming to me, although I agree that the C and C++ standards
offer a wide range of flexibility regarding diagnostics.

(It was certainly the intent of the original C++ proposal to
require "hard" checking of the top-level syntax inside [[ ]],
but perform token-eating inside the attribute-arguments-clause.)

> and the syntax used for contracts would cause a
> problem for that sort of implementation strategy.

I'm still not seeing that. A C implementation that ignores
everything inside [[ ]] would simply not be conforming to
a C standard that offers attributes using the proposed C++
syntax.

I'm not worried about old implementations; those would simply
not be able to compile C + contracts. Whether the diagnostic
ends up being a warning or an error seems QoI in any case.

> 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.
>
> (Additionally, I have personal reservations about the syntax chosen,
> but I want to keep that discussion separate so there's hopefully less
> confusion about what's a liaison concern and what's not.)

The alignment-specifier (in C++) also occupies the "attribute" grammar
slot, yet is not an attribute. Maybe having a specific suggestion for
alternative syntax that does not use [[ and ]] would allow us to make
progress here.

Jens