On Sun, Feb 8, 2026 at 6:34 PM Arthur O'Dwyer wrote:
>
> No, but commendable secondary goals. We see way too many proposals
> that do not consider implementability or teachability concerns, and many
> of them are adopted (either permanently or temporarily).


And in the case of NRVO, I think the lack of progress is because
Anton's paper is just too complicated to implement in compilers, and
also too much bother to write into the Standard.


> Now, sure, "ignorable attributes" is the law of the land, on paper,
> for now; but I don't think it's completely unreasonable for a std-proposals
> thread to imagine the future world where the law of the land has changed,
> not just for existing standard attributes like [[no_unique_address]] which are
> not ignorable, or existing vendor-specific attributes like [[gnu::section("foo")]],
> but for all attributes equally.


For unignorable attributes, maybe have [[[attrib]]] or [[<attrib>]]
or [[(attrib)]]


> You're missing tests for what happens with templates like this:
> template<class T> void f() { [[gnu::nrvo]] T t; return t; }
> template void f<std::mutex>(); // certainly OK
> template void f<int>(); // this should be OK, even though `int` is not NRVO-able, right? Because otherwise templates become kind of unusable?
> At the moment, as I write this, your compiler crashes on this example.


Thanks for that. I'm working on the code now to fix the ICE.
It will be 12:30pm though tonight British time before GodBolt gets updated.


> In fact you're missing any tests. "Hello world" examples are not tests. Your patch should touch GCC's test suite.
> You should include at least one test for a situation where the programmer has marked a variable with [[gnu::nrvo]]
> and returned it correctly, but where GCC's analysis fails to do the NRVO. I see that bug #53637 gives an example of
> such a situation; but adding your [[gnu::nrvo]] attribute to the return variable actually fixes that pessimization! Do you
> know why that is? are there other, less trivial, cases where adding the attribute doesn't fix the issue? and so on.


> (OTOH, the "fixed" code now emits a bogus -Wunused-but-set-variable warning, which seems very wrong.)

I'll stick this on the TO DO list too.