inout methods on a class are created like foo() & -> void. What is that ampersand doing there?

[tomFlowee]

As seen in various bugreports, users are having problems getting their head around this one. I would argue it is because there are more usecases that need to be handled differently.

Bugreport #900, #839 and #792 are the ones I found.

Todays state;

cppfont has some cool code to determine last usage of a variable. For things like unique_ptr to implicitly work this has been used to add a std::move and do the thing that people expect.

This creates a problem, however, for instances of self-made classes.

Imagine:

A: type = {
    connect: (inout this, s: std::string) = {
    }
}

main: (args) -> int = {
    a: A = ();
    a.connect("bar");
}

The variable a is allocated on-stack. The core language has a very clear set of rules on the lifetime. Which raises the question, when is it ever Ok to generate a 'std::move' wrapper for usage of this variable?

If 'connect' would be static, the above code would compile and actually the lifetime of a is still going to be till the end of the scope of main (as expected).

So why would it be useful to add a std::move to the call of connect() ?

People have stated I can work around this by explicitly discarding the instance of 'a' at the end. _ = a;. It does feel like that misses the point, I have no intention of discarding 'a', it is supposed to live till the end of main(). (usecase

Maybe someone can link to the underlying reason for the existance of the std::move that is currently generated, so we can find a way to make all usecases work.

Thanks for reading!

[gregmarr]

This isn't really connected to UFCS. You get the same behavior whether you call with member syntax or non-member syntax.

A: type = {}

connect: (inout arg: A, s: std::string) = {}

main: (args) -> int = {
    a: A = ();
    connect(a, "bar");
}

    A a {}; 
    connect(std::move(a), "bar");

[hsutter]

Thanks! This is a good question.

As background, please read "Design note: Explicit discard"

Consider your example, adding a comment:

A: type = {
    connect: (inout this, s: std::string) = {   // <=== note the INOUT here
    }
}

main: (args) -> int = {
    a: A = ();
    a.connect("bar");
}

If that inout were omitted (in is the default), this program compiles without error.

This highlights the reason the above code is getting the error: It is modifying a, then never looking at a again... the "out" value of a is dropped on the floor. It's the same case as if a returned value was never looked at and dropped on the floor, but in this case the returned value is the "out" value of this object.

My thinking is that making this break is a feature, not a bug. Looking at the code above, is it correct that the code modified a, but then immediately destroys it without using the new value it just cause a to have?

[tomFlowee]

Thanks!

The "leaking through" of hidden (mandatory) things like stuff suddenly becoming a smart pointer, the mandatory move semantics, the topic of this specific discussion and as a random point: "you can't use ->, please use *. are things that need work.

I understand the goals, but the learning cost is too great and long explanations non-withstanding, they really only make sense if you are actually the author of this conversion layer. For the rest of us they are just new bullets to aim at our feet.

Fast forward 5 years, I expect MS to not have backed down on the government threats, so these problems won't go away in cppfront. But we'll likely see a spin-off that takes all the nice things without the breaking "cpp1 is bad!" stuff and that may be actually useful for the larger audience.

Cheers!

[iprtel]

Please consider this:

ResultSet: type = {
    counter : int = 0;
    next : (inout this) -> bool = {
        counter++;
        return counter == 0;   // Always returns false
    }
    value : ( this) -> int = {
        return counter;
    }
}

test : () = {
    a:_ = new<ResultSet>();
    _ = a*.next();

    b:ResultSet = ();
    _ = b.next();
    _ = b;
}

test_if : () = {
    a:_ = new<ResultSet>();
    if (a*.next()) {
    }

    b:ResultSet = ();
    if (b.next()) {
        _ = b.value(); // [1]  
    }
    //_ = b; [2]
}

test_while: () = {
    a:_ = new<ResultSet>();
    while (a*.next()) {
    }

    b:ResultSet = ();
    while (b.next()) {
    }
}

main : () = {
    test();
    test_if();
    test_while();
}```

`ResultSet` represents the result of a query. Initially it points 'before' the actual result, with the first call to `next` it is internally moved to the first result if there is one. `next()` will return true only if a valid result is available.

This can be used in different ways:
1. if the caller is only interested if there is a valid result one call to `b.next()` will be sufficient.
2.  if the caller expects at most one result `if (b.next())` will do the trick. (Why is it sufficient to add the call in one branch that is never called?)
3. if the caller requires all results loop over the ResultSet

How can I explain the different handling of 'b' in all these cases where the pointer version can be used the same all the time?
Can I have a 'next(mutable this)` where the mutable indicates that the object might change, even if the caller is not interested in the change?

[JohelEGP]

(Why is it sufficient to add the call in one branch that is never called?)

The analysis doesn't consider execution.
What matters is that the use in the condition isn't the definite last use.
For that, a use after the condition (within the branch, or after the selection statement) suffices.

How can I explain the different handling of 'b' in all these cases where the pointer version can be used the same all the time?

The unique pointer is still moved.
But it is dumb, and always literally gives you what it points to.
It doesn't even propagate const.

If you switch to std::optional, which does forward rvalueness,
you then get an error just like the unwrapped case: https://cpp2.godbolt.org/z/qd3n76bbb.

Can I have a 'next(mutable this)` where the mutable indicates that the object might change, even if the caller is not interested in the change?

It was decided that there wouldn't be a keyword for this in a function declaration (somewhere in #231, I think).

[iprtel]

Thanks for your responses at this time of the year.

The analysis doesn't consider execution.
What matters is that the use in the condition isn't the definite last use.
For that, a use after the condition (within the branch, or after the selection statement) suffices.

I'm afraid lots of people will add CPP2_DISCARD(x); for every variable that the compiler complains at the end of a function.

The unique pointer is still moved.
But it is dumb, and always literally gives you what it points to.
It doesn't even propagate const.
If you switch to std::optional, which does forward rvalueness,
you then get an error just like the unwrapped case: https://cpp2.godbolt.org/z/qd3n76bbb.

That is interesting about the unique pointer. Could new return a std::optional of a reference type that cannot be set to null?
Then I could do a null check once after the new and then never bother again. That could also fix the issue here.

[gregmarr]

That's an interesting usage, it downcasts stuff to raw pointers to make it work.
Which is not very cpp2 style

Yeah, I'm not promoting that as a great method, just evaluating what's possible with the current analysis to see if the current analysis is appropriate.

[JohelEGP]

People have stated I can work around this by explicitly discarding the instance of 'a' at the end. _ = a;. It does feel like that misses the point, I have no intention of discarding 'a', it is supposed to live till the end of main().

Discarding isn't the same as destroying, so it doesn't affect the lifetime of a.
You're just explicitly stating that you're not using an "out" aspect of it, as Herb says.
In the case of calling an inout member, by discarding afterwards,
the move on last use becomes part of the discard, and that std::move, by itself, does nothing.

[hsutter]

Right, "discard" refers to the value.

This terminology (and syntax) does seem to follow the prior art in other languages mentioned in the design note.

Note that I didn't have C#'s experience in mind -- this is not C# envy or anything. 😉 I independently arrived at the _ = f(); discard syntax because Cpp2 already allowed _ as "don't care" in lots of places, and I wanted a way to say "I don't care about the result of f()," so _ = f(); seemed a natural way to write it, connoting 'assign the result to nothing/I-don't-care.' I think this is an example of convergent design/evolution, because I subsequently found C# had made the same choice, and presumably it was for similar reasons. Then when considering inout parameters, it seemed natural to use the same _ = obj; to say "see, I'm explicitly not looking at obj's value."

[hsutter]

BTW, I've just got to say that, even though ChatGPT does sometimes make mistakes(*), it's really impressive... "magical" as defined by Clarke, given that AFAIK no one, not even the AI designers, really deeply groks how it generates the output it does.

Considering that Cpp2 is a small personal project that only existed on the web in the past year, and yet I get this (using ChatGPT 4):

The link is the above-linked design note... cool.

Update: Here's another...

And this is just general-purpose garden-variety ChatGPT... it's not a dedicated Copilot that could have domain-specific training, and as far as I know it's not using any special plugin/gpt.

---

(*) The first time I asked it what cppfront was, it gave a completely correct synopsis except that it said the compiler was written by Bjarne Stroustrup. 😆 In writing this example I tried it again, and this time it got everything correct.

[tomFlowee]

I have the feeling we're actually mostly in agreement, but this is about a very different thing...

To put it in the most simple way; Why does this code compile, but my example does not?

#include <fstream>
main: (args) -> int = {
    a: std::ofstream = ();
    a.open("filename");
    // ^ a non-const method call that likewise returns
    //  nothing. Exactly like my 'connect' method intended to do.
}

I want my example to behave the same way, I call a non-const method on an object that has plenty of logic on it and I want the destructor to only be called at the end of the scope.

Ok, goal:

public: auto connect(cpp2::in<std::string> s) -> void;

try 1: A: type = { connect: (this, s: std::string) = { } }
gives: public: auto connect(cpp2::in<std::string> s) const& -> void;

try 2: A: type = { connect: (in this, s: std::string) = { } }
gives the same.

try 3: A: type = { connect: (out this, s: std::string) = { } }
gives: public: auto connect(cpp2::in<std::string> s) -> A& ;
that looks odd...

try 4: A: type = { connect: (inout this, s: std::string) = { } }
gives: public: auto connect(cpp2::in<std::string> s) & -> void;

try 5: A: type = { connect: (s: std::string) = { } }
gives: public: static auto connect(cpp2::in<std::string> s) -> void;

I'm out of creativity; how do I get a normal plain and simple void-returning, non-const method that is a member on a class? I think that is the same question as OP. How do I get a normal simple method I can call without qualifying as "dropping the result on the floor".

[JohelEGP]

Its the move constructor!

No, we want more regular types.

Curious about why you start it with "no". There is no disagreement here... Notice I didn't make some suggestions, like auto-generate move semantics more than already done. So, it's the move semantics that are relevant here!

I showed the code examples, I highlighted the cases where it is beneficial as well.

This highlighting of data flow is one of the things Cpp2 brings to the table.

And you can have this for stuff that needs it. Like a movable object.

You want to not have to explicitly discard the "out" aspect of a last use of a variable.
You're suggesting that what we really want is to have more move-only types.
But that would mean that regular types,
for which discarding the "out" aspect on last use makes no sense,
would stop being diagnosed in Cpp2 code.

This highlighting of data flow is one of the things Cpp2 brings to the table.

I think if you read the post you'll see that it doesn't actually work. Which is the reason why it keeps on coming back in bugreports.

I don't think bug reports equates not working.
Maybe it's just a combination of a teaching issue and adaptability.

Adding a std::move around a plain old data object has no effect. The generated code even honors the lifetime of objects till the end of the current scope.

That's just an implementation detail.
The Cpp1 code doesn't need that static_cast<void>(std::move(x));.
Maybe it should just lower to a comment in Cpp2 code: /* _ = x; */.

[JohelEGP]

Or CPP2_DISCARD(x);.

[tomFlowee]

You want to not have to explicitly discard the "out" aspect of a last use of a variable.

no, that is incorrect.

I"m claiming that calling a non-const method on an object does not create an 'out' in that calling context. It is being used, but not in the place where the variable is owned. Core example, in main().

I'm going to claim that discarding a variable makes scope VERY confusing. Is at best a workaround to a claim that something is an error which at best is a warning and many times is just normal correct usage.
And I've been claiming various times that the real bugs are being caught already in movable objects misusage.

You're suggesting that what we really want is to have more move-only types.

I literally said the opposite in the reply you quoted.

[JohelEGP]

Right, sorry.
What I said is the effect of what applying your model would be.

You're suggesting that what we really want is to have more move-only types.

I literally said the opposite in the reply you quoted.

Well, I'm confused.

[tomFlowee]

What I said is the effect of what applying your model would be.

I didn't propose any model. I observed that the current setup is very good at catching mistakes for a certain type of classes. Movable ones. Of which there are plenty. So the idea behind this is fine.

What I also observed is that the wish to detect unused variables and error out on them has a lot of issues, to which I observed that the idea at the core doesn't make sense since the compiler can't possibly know if a certain thing is correct or not.
And after programming with cppfront for 2 days, I also observe that it is much worse than a naggy IDE when you can't write code incrementally with compiles in the meantime.

So, my conclusion is that the design works fine but there is the WEIRD adding of an ampersand to the function declarations which should be removed for code that is meant to be compatible with cpp.

[realgdman]

I'd say its correct, and API of connect need to be improved. To something like streams or files, where after operation you have to assign returned value and check if connection/subscription was successful.

status := a.connect("bar");
if(status.is_ok()) ... 

Then, discarding returned value is actually meaninful error.

[JohelEGP]

This is the code from #900 (comment):

QCoreApplication app;
Client client;
client.connect(hostname, post);
return app.exec();

The relation between app and client is somehow implicit, perhaps through global state.
That doesn't play well with the local analysis of lifetimes.

[SebastianTroy]

Could perhaps evaluate to a boolean so you can "if (not a.connect()) ;" unless you're thinking there will be extra optional error information in the type? On 23 December 2023 18:04:52 realgdman ***@***.***> wrote: I'd say its correct, and API of connect need to be improved. To something like streams or files, where after operation you have to assign returned value and check if connection/subscription was successful. status := a.connect("bar"); if(status.is_ok()) ... — Reply to this email directly, view it on GitHub<#901 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AALUZQL6GYJXCGKQBDBJKWLYK4MMFAVCNFSM6AAAAABA5MCL22VHI2DSMVQWIX3LMV43SRDJONRXK43TNFXW4Q3PNVWWK3TUHM3TSMZVGAYDM>. You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[SebastianTroy]

I'd argue that the lifetime there is very explicit, you've created an object on the stack and returned from the function, what else would/should a programmer expect? I personally don't want a language with lifetime extension via spooky action at a distance! On 23 December 2023 18:21:52 Johel Ernesto Guerrero Peña ***@***.***> wrote: This is the code from #900 (comment)<#900 (comment)>: QCoreApplication app; Client client; client.connect(hostname, post); return app.exec(); The relation between app and client is somehow implicit, perhaps through global state. That doesn't play well with the local analysis of lifetimes. — Reply to this email directly, view it on GitHub<#901 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AALUZQOSFV3EPBZOTDWJZCLYK4OL3AVCNFSM6AAAAABA5MCL22VHI2DSMVQWIX3LMV43SRDJONRXK43TNFXW4Q3PNVWWK3TUHM3TSMZVGA4TC>. You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[tomFlowee]

For people that don't have experience with Qt, it uses asynchronous setup for things like networking.
So a 'connect' will instantly return, while at the same time set into action the low level stuff to open a connection.

When the async connect succeeds (or hard fails) you get a callback. At some event in the future.
Event handler-callbacks are the entire reason for there being a "client" object.

As a whole this means that the 'connect' instantly returns and since the 'app.exec()' is running the event-queue any sort of callbacks are (quite deep in the stack) run still in main(). Specifically, the 'client' object is still being used for those callbacks and all the things a client would actually do after the connection actually established.

But obviously no compiler could possibly know about any of that via some simple static analisis. For starters, the entire system I just described is provided as a dynamic library. Without debug symbols.

The code I linked somewhere in this thread actually calls a server and fetches data to look through it. It runs for about an hour with about a million callbacks being processed on the event queue before all relevant data has been found and it exits using the async method of Qt, calling the static QCoreApplication::quit() method that makes that 'exec()' call return.