From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm1-x32d.google.com (mail-wm1-x32d.google.com [IPv6:2a00:1450:4864:20::32d]) by sourceware.org (Postfix) with ESMTPS id C04A83857BBD for ; Fri, 15 Jul 2022 16:25:44 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org C04A83857BBD Received: by mail-wm1-x32d.google.com with SMTP id p26-20020a1c545a000000b003a2fb7c1274so621249wmi.1 for ; Fri, 15 Jul 2022 09:25:44 -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 :to:cc:references:content-language:from:in-reply-to :content-transfer-encoding; bh=FtwTsWEOfsbbDK6jHrbn/rEkv+wQLyFjidWGT+nOeCk=; b=csCQR1UEsLoqsr+e/cLevbRghG84clw3IBb8jtCv9uY68Mcj+ThmvW+VL85o+KOJCd JUTUFt4x5WcO8O2RvXN7wpFiV8ahcs2c6M/mHBR5W4PmS49Chbixd/KzyWpV7iGF26nY aalMpIu9vHIEYEa7odLDnbZzxjH0wtUA40kJzFHRlgh+5VRqXtcoQOwADuexGQ7aTb73 5DLPtUYt0W0ukBSSG+ZaPkTWLISVxWXZbpM9OyEHaj0+4RObzznSAPUMFH/cuT9n1i7P CwcoDCF43SQW6n309Ka4V+CUsLP5IDKBhYnyS9a9gLON6IA8FO4dE1w2WtLNrzcqZ37h 08iw== X-Gm-Message-State: AJIora+zWawe4RfmKniV3/JOwyRu7/aAhPBBihTHGMbSTcWNGL7uqLE9 qVQd2HQo46P3ndIY8ivvsL8= X-Google-Smtp-Source: AGRyM1t9CezmrzWXS9kF0syjq9metpfd6aemka7MrLvZO1Qo4XpcBCmh3zk1vVH98JjAWMOFsuOWCg== X-Received: by 2002:a05:600c:34ce:b0:3a0:3b4b:9022 with SMTP id d14-20020a05600c34ce00b003a03b4b9022mr15324904wmq.66.1657902342925; Fri, 15 Jul 2022 09:25:42 -0700 (PDT) Received: from [10.10.148.229] ([94.42.86.230]) by smtp.gmail.com with ESMTPSA id n6-20020a05600c4f8600b003a2f89c4bcesm9339974wmq.43.2022.07.15.09.25.41 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 15 Jul 2022 09:25:42 -0700 (PDT) Message-ID: Date: Fri, 15 Jul 2022 18:25:40 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101 Thunderbird/102.0.2 Subject: Re: Proposal: allow to extend C++ template argument deduction via plugins To: Ben Boeckel Cc: gcc@gcc.gnu.org References: Content-Language: en-US From: Dan Klishch In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-2.4 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, KAM_SHORT, NICE_REPLY_A, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.6 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: Fri, 15 Jul 2022 16:25:46 -0000 Hi Ben, Thanks for your feedback. The original problem I was trying to solve is to do such deduction in my own project where I use self-written wrapper around libpq, so naturally I'm not concerned if I'll be writing in pure C++ or C++ dialect. Actually, I tried to come up with a solution which makes as many opportunities open as possible, so it also allows to create almost any kind of decorators or magic functions, for instance, __builtin_format from here . Using plugins means that we are doing something incompatible somewhere and are fully aware of that. Furthermore, one already has a restricted ability to make arbitrary modifications to AST with the help of plugins via registering new pragmas and attributes, so I just only want to loosen restrictions. Returning to the use case regarding libpqxx, one can make specifying return types optional when compiling with a plugin and mandatory otherwise. So then if the code is compiled with the plugin, schema and query available and types are not omitted, the plugin can check the types instead of inferring. Also, I believe the aforementioned is possible in Haskell (I only briefly read project description) . Thanks, Dan Klishch On 7/15/2022 4:18 PM, Ben Boeckel wrote: > On Thu, Jul 14, 2022 at 18:46:47 +0200, Dan Klishch via Gcc wrote: >> As far as I understand the currently available plugin extension points, it is >> not possible to modify template argument deduction algorithm (except the >> theoretical possibility to completely override parsing step). However, such >> opportunity might be beneficial for projects like libpqxx, for example, when >> database schema and query text are available at compile-time, return types of >> the query might be inferred by the plugin. >> >> I propose to add something like PLUGIN_FUNCTION_CALL plugin_event which will >> allow to modify function calls conditionally. Will a patch adding such >> functionality be welcomed? > Note that I'm not a GCC developer, so my opinion isn't worth much on the > acceptability-to-GCC front. > > Wouldn't this make it a C++ dialect? How would non-GCC compilers be able > to be compatible with such an API? That is, if the schema and query > being available changes the API (nevermind the schema itself changing), > I don't see how this works in general. > > --Ben