On Wed, Sep 28, 2022 at 12:42 AM Phil Bouchard <boost@fornux.com> wrote:

On 9/27/22 12:39, Jason McKesson via Std-Proposals wrote:


Give us a 3 paragraph summary of what exactly you want changed in the
C++ standard. No links, no off-ML resources. Just state plainly the
exact thing you want changed in the C++ standard. I'm not asking for
standardese; I'm asking for the specific thing you want the language
to do.

What I am proposing here is to create a framework to allow the addition of:

- implicit parameters;

- implicit class members;

- implicit function variable instances;

- implicit compound statement variable instances;

- implicit file-scope static variable instances.

For "local" (non-system) files that are being compiled for a local project.

When you say "implicit", like, what does that mean? Do you mean that
this construct injects, for example, function parameters into a
function declaration/definition that did not have them before, along
with the code needed to do something with those parameters? All
without the affected code having any text requesting such injection?
And presumably without the calling code being aware of these
parameters either?

Good questions. Yes it would inject new code to only "local" functions and classes. The Clang API is already capable to distinguish local and system files so we can properly manage the calling code as well. This way maybe we can export that feature to the standards, or find some syntax to explicitly or implicitly tag functions and classes we want to manage.

Because that latter part, about nobody being aware this is going on,
is kind of a sticking point. Basically every kind of generative
reflection idea which operates on a function or class requires that
the function/class asks for it via some kind of syntax. Some of them
can operate on functions/classes that didn't request it in their
declarations, but they cannot *modify* those functions/classes
in-situ. These generative mechanics can manufacture a new
function/class that interacts with the old one, but they can't
actually change the old one.

For some kind of generative reflection to automatically go out and
modify any syntactic construct arbitrarily is leaving the bounds of
"generative reflection" and entering the domain of a pre-compilation
tool. And while a pre-compiler tool might be useful, it's not
something that C++ *itself* should be defining. It is by definition
outside of the domain of the language.

The goal here is to extend the language, on its architectural scale, to fix somehow these long lasting issues in C++. No matter how long it can take, they have to be fixed.

--

Phil Bouchard CTO T: (819) 328-4743 E: phil@fornux.com | www.fornux.com 1188 rue Saint-Louis | Gatineau (Qc), J8T 2L8 Canada

Le message ci-dessus, ainsi que les documents l'accompagnant, sont destinés uniquement aux personnes identifiées et peuvent contenir des informations privilégiées, confidentielles ou ne pouvant être divulguées. Si vous avez reçu ce message par erreur, veuillez le détruire. This communication (and/or the attachments) is intended for named recipients only and may contain privileged or confidential information which is not to be disclosed. If you received this communication by mistake please destroy all copies.