From: Alejandro Colomar <alx.manpages@gmail.com>
To: Jonathan Wakely <jwakely.gcc@gmail.com>
Cc: Jakub Jelinek <jakub@redhat.com>,
"gcc@gcc.gnu.org" <gcc@gcc.gnu.org>,
Joseph Myers <joseph@codesourcery.com>
Subject: Re: [C2x] Disallow function attributes after function identifier
Date: Sat, 11 Jun 2022 11:03:04 +0200 [thread overview]
Message-ID: <ded635a8-6204-d088-e009-f9c3821f4b54@gmail.com> (raw)
In-Reply-To: <CAH6eHdS30Pg8HgjUx7NMRTdpXNesyuzC9FmivdvJFB2AWGvMUg@mail.gmail.com>
[-- Attachment #1.1: Type: text/plain, Size: 2696 bytes --]
Hi Jonathan,
On 6/11/22 00:47, Jonathan Wakely wrote:
> Well, I'd argue the same reasons to remove it from C++. Don't know how
> useful that feature is for C++, though. I bet not much, but am not an
> expert in the language.
>
>
> It's used in libstdc++ because I couldn't get an attribute to work in
> any other location, because it isn't valid at other positions in a
> constrained function template. So no, we can't remove it from C++.
>
Hmm, okay, not removable in C++. I'm curious about the specific line of
code, if you have it around and could link to it. But C++ is huge, so
anything is to be expected :)
>
>
>
> But, are we sure we want to add this to C? You know how difficult
> is to
> revert mistakes in C, as opposed to C++, where additions and
> deprecations are more common.
>
>
> To the core language grammar? Are you sure about that?
Well, everything is relative.
libstdc++ additions, deprecations (and undeprecations) are much more
common than in the core C++ language (e.g., the deprecation and later
undeprecation of <std*.h> headers).
But breaking changes in the core C++ language are still more common than
in C, where (sadly) we still have the useless 'auto' for backwards
compatibility with dead languages, which would be nice in macros with
the meaning of __auto_type. Maybe in the 2050s? :P
So, C++ needs this feature.
Then in C, we don't need it (I've never seen code reusing the return
type to declare more than one function, and I hope to never see that
apart from theoretical investigation). `int foo(void), bar(void);`
seems a useless feature in the language to me, but maybe disallowing it
through an exception to the rules would complicate the wording more than
help, so if that's kept in the language, I'm fine with it.
So we could, and also could not, bring the C++ attribute for that
useless feature.
In C, I don't think that attribute position can have a useful use case
that can't be achieved by an attribute at the start of the prototype,
since the language is much simpler.
Do we want to add a completely unnecessary feature, just for symmetry
with C++, even if it poses a danger of breaking (both human and script)
readability of function declarations/definitions, especially when hidden
in macros?
I still have the hope that if the feature is finally kept in C23,
absolutely no-one will ever use it, but then I question the introduction
in the first place.
Cheers,
Alex
--
Alejandro Colomar
Linux man-pages comaintainer; http://www.kernel.org/doc/man-pages/
http://www.alejandro-colomar.es/
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
next prev parent reply other threads:[~2022-06-11 9:00 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-06-10 20:40 Alejandro Colomar
2022-06-10 21:09 ` Joseph Myers
2022-06-10 21:35 ` Alejandro Colomar
2022-06-10 21:16 ` Jakub Jelinek
2022-06-10 21:31 ` Alejandro Colomar
2022-06-10 22:47 ` Jonathan Wakely
2022-06-11 9:03 ` Alejandro Colomar [this message]
2022-06-11 12:08 ` Gabriel Ravier
2022-06-11 20:20 ` Alejandro Colomar
2022-06-13 15:54 ` Jonathan Wakely
2022-06-11 12:53 ` Jonathan Wakely
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=ded635a8-6204-d088-e009-f9c3821f4b54@gmail.com \
--to=alx.manpages@gmail.com \
--cc=gcc@gcc.gnu.org \
--cc=jakub@redhat.com \
--cc=joseph@codesourcery.com \
--cc=jwakely.gcc@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).