Hi Frederick,

On 2026-02-09T13:12:57+0000, Frederick Virchanza Gotham via Std-Proposals wrote:
> 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)]]

I'm working on non-ignorable attributes in ISO C2y. There seems to be
some consensus being built (but not yet there) that non-ignorable
attributes should be scoped ones (similar to vendor ones), just with
a standard prefix. I think the best prefix would have to be either
[[::attr]] or [[std::attr]].


Have a lovely night!
Alex

>
>
> > 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.
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals

-- 
<https://www.alejandro-colomar.es>