From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mailrelay.tugraz.at (mailrelay.tugraz.at [129.27.2.202]) by sourceware.org (Postfix) with ESMTPS id 1015A3858D28 for ; Mon, 4 Dec 2023 19:13:33 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 1015A3858D28 Authentication-Results: sourceware.org; dmarc=pass (p=quarantine dis=none) header.from=tugraz.at Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=tugraz.at ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 1015A3858D28 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=129.27.2.202 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1701717223; cv=none; b=hRqeqbBoeyEJ4LifeTAWLjo70+bhAOagtot9oF2dvWHuriS9Q2y4TyJ7wGJWE5a6VdozysSlxjEECAvrsxa5xFAmtLXVMH50ZENYEquNqL8bA6Lu5P3fQJ35FnuTgTaewhDAOo42eGoGVInCVt1HEYo1LMdzIJLp3E+vFIn5ogY= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1701717223; c=relaxed/simple; bh=czfSrMw0ZfIu/oMzw28zW1bCMSmgmFmaZvLuNOjv+ME=; h=DKIM-Signature:Message-ID:Subject:From:To:Date:MIME-Version; b=dVcDyb3NtYHbCQNI2s6vtEi/laD6D58IZAfZpAkhQ8uELnBMbK/1qHgMRR0Ne9RQcdKQJiztemaMVu1elwhwqG4JflbA/46JE24QTk+gJuw2dOZ6t9IBYOaDrtVadhpHHDu2leV2rwl1RkBgkYVzELJWQOl2UaQw2M8LqsRNR9s= ARC-Authentication-Results: i=1; server2.sourceware.org Received: from vra-168-61.tugraz.at (vra-168-61.tugraz.at [129.27.168.61]) by mailrelay.tugraz.at (Postfix) with ESMTPSA id 4SkYGr3vSFz3wcb; Mon, 4 Dec 2023 20:13:24 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tugraz.at; s=mailrelay; t=1701717205; bh=bi0KhQCIQAKHWoYqhdfkupMqbGjKLvYh8LZ2JYt3g4U=; h=Subject:From:To:Cc:Date:In-Reply-To:References; b=EjXHU3tKrkHjps/aROKgjkK+gUYOsARAzEY2eUxcUvZ6D7bqi5U0WyydwuyRN4no0 PmvhIJhs8hbLIDCVmAZh4JB9MNnuF22S0YBFZc35dau/B81pUypMGIUBTFvfxdtyea YC1Ed1ikgHYDZu42/p3/l5A5iwBzX8nMJkeaCeKc= Message-ID: Subject: Re: [gcc15] nested functions in C From: Martin Uecker To: Jakub Jelinek , Siddhesh Poyarekar Cc: Andreas Schwab , polacek@redhat.com, gcc-patches@gcc.gnu.org Date: Mon, 04 Dec 2023 20:13:24 +0100 In-Reply-To: References: <7862c488-5afd-4018-9dc5-c72d9382a052@gotplt.org> <48690099bc3fb6030191d2c58525fcfc415da107.camel@tugraz.at> <3b959c8a-0a65-4185-a943-122bb898796f@gotplt.org> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable User-Agent: Evolution 3.46.4-2 MIME-Version: 1.0 X-TUG-Backscatter-control: G/VXY7/6zeyuAY/PU2/0qw X-Spam-Scanner: SpamAssassin 3.003001 X-Spam-Score-relay: -1.9 X-Scanned-By: MIMEDefang 2.74 on 129.27.10.116 X-Spam-Status: No, score=-4.0 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL,SPF_HELO_NONE,SPF_PASS,TXREP,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: Am Montag, dem 04.12.2023 um 19:51 +0100 schrieb Jakub Jelinek: > On Mon, Dec 04, 2023 at 01:27:32PM -0500, Siddhesh Poyarekar wrote: > > [Branching this into a separate conversation to avoid derailing the pat= ch, > > which isn't directly related] > >=20 > > On 2023-12-04 12:21, Martin Uecker wrote: > > > I do not really agree with that. Nested functions can substantially > > > improve code quality and in C can avoid type unsafe use of > > > void* pointers in callbacks. The code is often much better with > > > nested functions than without. Nested functions and lambdas > > > (i.e. anonymous nested functions) are used in many languages > > > because they make code better and GNU's nested function are no > > > exception. > > >=20 > > > So I disagree with the idea that discouraging nested functions leads > > > to better code - I think the exact opposite is true. > >=20 > > I would argue that GNU's nested functions *are* an exception because th= ey're > > like feathers stuck on a pig to try and make it fly; I think a signific= ant > > specification effort is required to actually make it a cleanly usable > > feature. >=20 > Why? The syntax doesn't seem to be something unexpected, and as C doesn'= t > have lambdas, one can use the nested functions instead. > The only problem is if you need to pass function pointers somewhere else > (and target doesn't have function descriptors or something similar), if i= t > is only done to make code more readable compared to say use of macros, I > think the nested functions are better, one doesn't have to worry about > multiple evaluations of argument side-effects etc. And if everything is > inlined and SRA optimized, there is no extra cost. > The problem of passing it as a function pointer to other functions is > common with C++, only lambdas which don't capture anything actually can b= e > convertible to function pointer, for anything else you need a template an= d > instantiate it for a particular lambda (which is something you can't do i= n > C). In C++ you can erase the type with std::function. C is missing a=C2=A0 function pointer type which can encapsulate the static chain on all archs (not only for nested functions, also for language=C2=A0 interoperability). Martin >=20