Proposal: allow to extend C++ template argument deduction via plugins

Proposal: allow to extend C++ template argument deduction via plugins

[Dan Klishch]

Hi,

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?

Thanks,
Dan Klishch

Re: Proposal: allow to extend C++ template argument deduction via plugins

[Ben Boeckel]

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

Re: Proposal: allow to extend C++ template argument deduction via plugins

[Dan Klishch]

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
<https://gcc.gnu.org/pipermail/gcc/2022-July/239025.html>.

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) <https://github.com/dylex/postgresql-typed>.

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