What you want is this:

If it can RVO it will RVO.

The rule that seems sensible to me is as follows, at any given scope there must not be more than 1 candidate considered for RVO with overlapping lifetimes.

Example 1:
Imovable get()
{
 {
  Imovable A;
  if(condition()
  {
   return A; //Ok
  }
 }
 return Imovable{}; //Ok lifetime of temporary is not overlapping with A
}

Example 2:
Imovable get()
{
 Imovable A;
 if(condition()
 {
  return A; //Error
 }
 return Imovable{}; //Error lifetime of temporary overlaps with A
}

Example 3:
Movable get()
{
 if(condition()
 {
  return Movable{}; //RVO
 }
 {
  Movable A;
  Movable B;
  //...
  if(condition()
  {
   return A; //RVO, only A is considered for RVO
  }
 }
 {
  Movable A;
  Movable B;
  //...
  if(condition()
  {
   return A; //Move, both A and B are considered for RVO
  }
  else
  {
   return B; //Move, both A and B are considered for RVO
  }
 }
 return Imovable{}; //RVO
}

No new keyword is necessary, no new library facility needed, movable or unmovable it is an optimization that could be applied everywhere. No need to consider if returning an immovable object by value makes sense.

If it is ever going to make it into the language, it is going to look like this ^
It may be tricky to figure out which are RVO candidates and would their lifetimes overlap, the rule looks sensible, just not sure if it covers all the possible corners cases that would make it unimplementable.

But one thing is for sure, the motivation for this will never be "in order to return a locked mutex by value from a function".
That will get rejected immediately. That motivation shouldn't appear on the paper. A neither should "My main argument in favour of having NRVO is just simple a visceral feeling that...", that is not an argument.

Are we clear?





-----Original Message-----
From: Std-Proposals <std-proposals-bounces_at_lists.isocpp.org> On Behalf Of Frederick Virchanza Gotham via Std-Proposals
Sent: Thursday, May 23, 2024 10:49
To: std-proposals_at_[hidden]
Cc: Frederick Virchanza Gotham <cauldwell.thomas_at_gmail.com>
Subject: Re: [std-proposals] std::elide

On Thu, May 23, 2024 at 12:57 AM Thiago Macieira wrote:
>
> They why are you insisting on it, despite being asked multiple times
> to find other uses?


I'm not insisting on it. It's an example. Sort of like how last year I demonstrated a strange physical exercise to my shoulder surgeon to show him the range of motion I had after my surgery -- he could have barked back at me that nobody would ever deliberately move their shoulder that way, and he would have been right (it was certainly a peculiar motion), but he had gumption to know that I was merely using the movement as a demonstration, as an example of what my shoulder can do.


> Tiago's argument was that the reasons why you don't want to do that
> for std::mutex may apply to for any other class type, so he's asking
> you to give a couple of real examples where the feature would be
> useful and what alternatives exist.


Look I realise that there's more than one personality on this mailing list, and I accept that two rational and intelligent people can form very different opinions about a topic given the same evidence and observations, so I don't claim to have a monopoly on the truth there.
I had perceived that Tiago was focusing specifically on the 'std::mutex' class, whereas you appear to have perceived Tiago to have been making a more generic point along the lines of "It's pointless for mutexes and it's pointless for every other class too". If we were to agree that it's the latter rather than the former, then that's a very different discussion. That other discussion would be about whether NRVO ever makes sense at all for any type in any scenario.


> > No matter how many times it's re-iterated on this mailing list that
> > the whole locked mutex thing is just a quick-and-easy example, more
>
> And that's the issue. Stop giving quick-and-dirty examples because
> they lead people to the wrong path. Give a *proper* example.


A handful of extremely skilled programmers on this mailing list latched onto my mutex example because it's simple and shows the principle. And while I'm not a mind reader and haven't conducted a survey, I estimate that 9 out of 10 people here knew that std::mutex was being used for only one reason: It's unmovable and uncopyable. No other reason.


> Not a gimmick class either. A real one. Preferably, three different
> ones, so we know this is a real problem, not just an accident of bad API design somewhere.


So I think you want to change the discussion from:
    "Reasons why you'd never want to return a locked mutex by value from a function"
to:
    "Reasons why you'd never want to return a post-constructionally-modified class type by value from a function"

And that might actually be a very interesting discussion. My main argument in favour of having NRVO is just simple a visceral feeling that "This is something that we should have in our toolbox", as I want
C++ to be versatile and have all sort of features that can be used in
all sorts of ways. But when it comes down to it, if I think back on the C++ programs I've been writing since 2002, I actually have never needed NRVO. Even today, 22 years later and being gainfully employed to program microscopes and their supporting desktop PC software, I haven't ever come across a scenario where I need NRVO. The only scenarios that even came close to needing NRVO, I probably just used an std::optional.

So maybe NRVO actually is pointless and not worth writing into the Standard, so maybe we should all just use std::optional (in combination with std::elide -- see paper P3288). With that said though, I never needed RVO either but that made it in C++17.
--
Std-Proposals mailing list
Std-Proposals_at_lists.isocpp.org
https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals