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
