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_at_[hidden]> 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_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>