Eons ago (pre-any standard) when I was much more novice, I played with the idea of a 'local this' much like a 'with(...){...}' or a 'using(...){...}', but it quickly became much too complex. This almost became an anonymous local function and I abandoned the idea as a folly.

At an EWG, WG21 meeting a few years ago, an idea was discussed for exporting values from a local block and it quickly unraveled with complexity and confusion, for many of the same reasons, along with how to specify the return/exported variable(s) and type(s), and extending inner variables life times.

Anything you need to do in an inner block can be done using lambdas & capture, but without a local this.

Issues of a local this & local block:
how do you export values from the local block, 
can you have a local return, (no way to specify the return type)
can the inner block use variables of the outer block, 
how do you return out of foo() from inside the inner block.
if a member function, 
if inside the block you call a member function of the outer type
what happens to the outer this, (hidden or blocked?)
does the outer this become a second class this and is only used if no matching function is found
how do you reference the outer this from within the block, 
(hacky workaround) assign it outside the block to a pthis, then reference the pthis-> inside the block

[different scenarios, not equivalent functionality]

void myclass::foo (A a, B* b, C& c) {
myclass* pthis = this;
b->{  // b becomes 'this'
doSomething();
doSomethingElse();
pthis->trySomethingElse();
}
//or
c.{   // &c becomes 'this'
doSomething();
doSomethingElse();
myclass::trySomethingElse(); //calls myclass::trySomethingElse()
}
//or
D d = b->{
doSomething();
doSomethingElse();
// some other calls
return trySomethingElse(); //calls myclass::trySomethingElse() and local return the value out of the block
}
//or
D d;
a.{
doSomething();
doSomethingElse();
// some other calls
d = trySomethingElse();   //backdoor local return (side-effect)
}
}



On Fri, Mar 21, 2025 at 11:55 PM Vaibhav Parate via Std-Proposals <std-proposals@lists.isocpp.org> wrote:
Hello,
Before I spend time on a formal paper for this idea, I want some feedback and suggestions.

Idea:
I'd like to propose a with block for C++ that allows extending the scope of objects, making field access easier and reducing redundant qualifiers.

Motivation (while working on some personal projects):
Currently, in C++, working with objects often requires repeatedly qualifying fields with object-> or object. inside functions and lambdas. This leads to unnecessary verbosity, especially when dealing with deeply nested structures.

Example:
C++ Currently (It is readable but very quickly gets messy, specially when you are the author of the entire codebase):
void foo (A a, B* b, C& c) { // let's assume A, B, and C are types
a.doSomething();
b->doSomethingElse();
// some other calles
c.trySomethingElse();
}

C++ with "with" blocks:
void foo (A a, B* b, C& c) {
with (a, *b, c) {
doSomething();
doSomethingElse();
// some other calles
trySomethingElse();
}
}

Or if you want to use them for the entire function? Consider this:
void foo (A a, B* b, C& c) with (a, *b, c) {
doSomething();
doSomethingElse();
// some other calles
trySomethingElse();
}

What about field name collisions?
They can be easily solved using existing syntax of using object. or object->.

Maybe it will be harder for people to port old code that uses "with" as an identifier (variable name etc.) what about that?
It's not necessary to use this exact keyword, it can be something else like "using" which is already a keyword.

Why?
I always find it annoying to use qualifiers while initializing objects, yeah there are constructors (and other initializers), but there are sometimes where constructors aren't enough and the object needs to be initialized in different ways. I may be wrong here and maybe the only one facing these issues, but does it hurt to have this feature?
--
Std-Proposals mailing list
Std-Proposals@lists.isocpp.org
https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals