Hi Jason,

On 2026-02-09T21:09:40-0500, Jason McKesson via Std-Proposals wrote:
> On Mon, Feb 9, 2026 at 7:17 PM Alejandro Colomar
> <une+cxx_std-proposals_at_[hidden]> wrote:
> >
> > Hi Jason,
> >
> > On 2026-02-09T18:33:06-0500, Jason McKesson via Std-Proposals wrote:
> > > > The good thing about attributes is that placing rules are clear. If we
> > > > add new keywords, that increases syntax complexity. Using scopes
> > > > attributes, the syntax stays untouched.
> > >
> > > That's nice for computer usability and readability, but it does
> > > nothing for *human* usability and readability. Indeed, it makes those
> > > things worse.
> >
> > I'm going to strongly disagree. I still remember the first time I saw
> > a function-like keyword in some source code, back when I was learning C.
> > I don't remember the exact keyword, but I remember it was a vendor
> > attribute in a function declaration. It was something like this:
> >
> > void foo(int a) bar();
> >
> > You can imagine me --a then inexpert C programer-- thinking "WTF is
> > this?!". What's the function? What are its parameters? Does it have
> > one parameter 'a'? Or no parameters? Is it called foo() or bar()?
> >
> > With attributes syntax, it would have been
> >
> > void foo(int a) [[bar()]];
> >
> > Which anyone knowing that [[]] encloses attributes would recognize as
> > "this somehow modifies the declaration; look the documentation for the
> > precise attribute for the details".
>
> Why would a person who is an "inexpert C programer" know about the
> minutiae of syntax like attributes?

At least they'd know "this is something new to learn". Still much
better than "how do I even read this?".

Remember that if a computer has problems parsing code, a human brain
will face similar problems when deciding how some complex code has to be
read.

> `noexcept` (which is what I presume you're referring to) does not
> "modify the declaration;" it is an inexorable *part* of the
> declaration, as much a part of it as `foo`. It can even be part of the
> function's type.

I was thinking of [[reproducible]], or [[gnu::aligned()]], for example.

Of course they are part of the declaration. They modify the declaration
in the sense that they declare something similar to if the attribute
wasn't there, and the details of the difference depends on the specific
attribute used.

>
> Furthermore, we don't want it to appear on the left of the function
> name. It needs to be able to access the parameter names declared in
> the parameter list. So it must appear to the right of the parameter
> list.
>
> > > The attribute syntax was introduced with the understanding that they
> > > would be ignorable. They could have Godawful syntax because you
> > > weren't supposed to interact with them that much.
> >
> > I don't think it's awful.
>
> It makes the text significantly longer. Just taking the example under
> discussion, `nrvo` is 4 characters. `[[::nrvo]]` is 10 characters, 6
> of which carry no useful information. It's basically "Here's an
> attribute, it's really a keyword,

I find that part to be actually quite informative.

> that keyword is 'nrvo'". It's taking
> up a lot of space to introduce the actually important part of the
> text: "nrvo".
>
> We don't need 6 characters to say something is a keyword.
>
> > I like _Upper and __lower just fine, and
> > don't think [[attr]] is much worse than that. You get used to the
> > spelling of things. FWIW, I use _Generic() often, and never felt the
> > need for a generic() macro wrapping that.
> >
> > > That's why the
> > > `[[override]]` and `[[final]]` attributes became the `override` and
> > > `final` contextual keywords, and all of our lives were made better
> > > because of that.
> > >
> > > Attributes are supposed to be rarely used tools for very specific
> > > communication with compilers, not replacements for keywords because
> > > it's easier to standardize an attribute than an actual keyword.
> >
> > And they should remain rarely used.
>
> That won't happen if they become all-purpose keyword dispensers.
>
> The moment you start saying that attributes get to have an actual
> effect on the behavior of the program, then you have made a tool for
> standardizing keywords that you couldn't justify getting standardized
> as an actual keyword. That is the net result of this line of thinking:
> attribute syntax will go *everywhere*.
>
> > FWIW, I don't use _Alignas() often, and I think it would be much better
> > as an attribute [[::alignas()]]. I never remember where _Alignas()
> > goes in a declaration. But if it were an attribute, I'd only need to
> > remember the rules for attributes, which are relatively simple.
>
> ... in the grammar, it's literally considered an
> "attribute-specifier". The rules for their placement are the same.

Is it a type attribute? A variable attribute? It's quite unclear to
me from the specification. If we have several of these, each with its
own rules, it's going to get quite difficult to read C code.

>
> And no, the rules for attributes are not "relatively simple". In a
> type declaration, the attribute goes to the left of the type name.

I'm not sure what you mean.

 alx_at_devuan:~/tmp$ cat type.c
 typedef int T [[deprecated]];
 alx_at_devuan:~/tmp$ gcc -S -Wall -Wextra type.c
 alx_at_devuan:~/tmp$

> Unless it's a `using` declaration, where it goes to the right of the
> name before the `=`.

I don't know C++ enough. The rules in C are simple enough. I agree C++
is complex in general, and attributes probably aren't different.


Have a lovely day!
Alex

> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals

-- 
<https://www.alejandro-colomar.es>