Date: Wed, 28 Sep 2022 10:25:55 -0400
On 9/28/22 10:01, Jason McKesson wrote:
> On Wed, Sep 28, 2022 at 12:42 AM Phil Bouchard<boost_at_[hidden]> 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.
> On Wed, Sep 28, 2022 at 12:42 AM Phil Bouchard<boost_at_[hidden]> 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.
-- Email Signature Logo <https://www.fornux.com/> *Phil Bouchard* facebook icon <https://www.linkedin.com/in/phil-bouchard-5723a910/> CTO T: (819) 328-4743 E: phil_at_[hidden]| www.fornux.com <http://www.fornux.com> 1188 rue Saint-Louis| Gatineau (Qc), J8T 2L8 Canada Banner <https://goglobalawards.org/> 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.
Received on 2022-09-28 14:25:56