From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wr1-x42a.google.com (mail-wr1-x42a.google.com [IPv6:2a00:1450:4864:20::42a]) by sourceware.org (Postfix) with ESMTPS id 7FA1A38D30FA for ; Sat, 11 Jun 2022 12:09:01 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 7FA1A38D30FA Received: by mail-wr1-x42a.google.com with SMTP id u8so1624261wrm.13 for ; Sat, 11 Jun 2022 05:09:01 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent:subject :content-language:to:cc:references:from:in-reply-to :content-transfer-encoding; bh=3eQJXtBdqlevuywe8I7rDwF2OXHRo6Spw5fO7ltt+ag=; b=2fAWnftE6OfAlW744+QgEM8OjNeGjj/bdTnjZbvbdxjlGvSpjfhSK76UL3YCWjATEa 9X9rdG78lZyP0nqIcF16NiT9E/A9NUPwIohd5gkuxO9LBPDy67x9GFJ02WCsypuECIO6 PqkJGaIjzv0XgmZICKwJ7uCvFi/hsi/q+QAMCxb6//HsMAJsGy6v7URfCw3MeQDvUfaV 3YX3J07XgXmjQWkIHbWo1p/+atPVtk9JTIdb1nvWehvIFVe0t9QNvMsy0eREPaFUGos8 2Sjv0ndYRbketRKGLCXSJOtB9j4JaByskE5Y8UTAJw3CCj7O64cJTRRPDrmCtUy71AaU 1c1g== X-Gm-Message-State: AOAM532LxcGv+UWUQULGjmIWBF9JQ2PvgyIyKHk7yzfM5IPD/mKovSNW GgJC2GjRSKP7uPDNuW2LhD4= X-Google-Smtp-Source: ABdhPJx+EXF1gcWb4qV2/21vEC19Ovi9j9UYqXSrLKvgAzzhkDpYgxoP0uKTVmxBYQ5jo5OYGcnmDA== X-Received: by 2002:adf:ae09:0:b0:20e:e4f0:2133 with SMTP id x9-20020adfae09000000b0020ee4f02133mr48628571wrc.104.1654949340095; Sat, 11 Jun 2022 05:09:00 -0700 (PDT) Received: from [10.18.0.4] ([45.89.174.66]) by smtp.gmail.com with ESMTPSA id f6-20020a05600c154600b0039c5ab7167dsm6712520wmg.48.2022.06.11.05.08.59 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 11 Jun 2022 05:08:59 -0700 (PDT) Message-ID: <02b74788-43b3-da53-8f3b-3b114329f8d6@gmail.com> Date: Sat, 11 Jun 2022 14:08:57 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.10.0 Subject: Re: [C2x] Disallow function attributes after function identifier Content-Language: en-US To: Alejandro Colomar , Jonathan Wakely Cc: Jakub Jelinek , "gcc@gcc.gnu.org" , Joseph Myers References: <520a1013-ec4a-b3ca-871b-5e8110f61d37@gmail.com> From: Gabriel Ravier In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=1.0 required=5.0 tests=BAYES_00, BODY_8BITS, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, NICE_REPLY_A, RCVD_IN_ABUSEAT, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP, T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.6 X-Spam-Level: * X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org X-BeenThere: gcc@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Jun 2022 12:09:05 -0000 On 6/11/22 11:03, Alejandro Colomar via Gcc wrote: > 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 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 actually don't get the trouble with this. Your tool already can't parse declarations if they don't follow a certain coding style, so you can just add this restriction to the coding style that's required. > 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. Well in the same way, `int long signed const typedef long x;` is valid C, and I do hope that nobody will ever use it, but I don't think we should change C's grammar to disallow it. > > Cheers, > > Alex > Cheers, Gabriel