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?

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

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

And no, the rules for attributes are not "relatively simple". In a
type declaration, the attribute goes to the left of the type name.
Unless it's a `using` declaration, where it goes to the right of the
name before the `=`.