niedz., 8 lut 2026 o 19:34 Arthur O'Dwyer via Std-Proposals
<std-proposals_at_[hidden]> napisał(a):
>
> On Sun, Feb 8, 2026 at 7:06 AM Jens Maurer via Std-Proposals <std-proposals_at_[hidden]> wrote:
>>
>> On 2/8/26 01:55, Frederick Virchanza Gotham via Std-Proposals wrote:
>> > To achieve NRVO in C++, I think we need a happy medium between three things:
>> > (1) Good enough functionality and convenience for programmers
>>
>> Sure.
>>
>> > (2) Not too much hassle for compiler writers
>> > (3) Not too much complication for standards writers
>>
>> Not among the primary goals of a proposal.
>
>
> 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).
>
>
>> > I think the happy medium is to mark the return slot as follows:
>> >
>> > mutex Func(void)
>> > {
>> > [[nrvo]] mutex m;
>> > m.lock();
>> > return m;
>> > }
>>
>> [... rules omitted ...]
>>
>> How does this use of an attribute fit the idea that attributes
>> have optional semantics, given that the program will be ill-formed
>> without the attribute present?
>
>
> It doesn't. Nobody likes the "ignorable attribute rule." See for example

False, I like how they are handled :P
Only problem is people try sove in things that they should not.

First of all, non-ignorable attributes should be explicit and ilformed
even if the compiler does not know them even in C++11.
I suggested adding the prefix `!!` for one like this, this could be
any symbol that makes C++11 reject this code and make this feature
backward and forward compatible.
This will make a clear distinction between these two versions.

> https://brevzin.github.io/c++/2025/03/25/attributes/
> 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.
>
> Some proposals, such as P1144 [[trivially_relocatable]], have attempted to navigate the current rule by indicating that implementations are permitted to ignore the attribute, but are recommended to leave `__has_cpp_attribute(x)` false unless attribute `x` actually has the Standard-mandated effect. This allows user-hostile-yet-conforming implementations to ignore the attribute, while still allowing programmers to test for support (and complain to their compiler vendors if the attribute is not supported).
>
>
>> Here's the compiler patch:
>> https://github.com/healytpk/gcc-thomas-healy/commit/tag_nrvo
>> https://godbolt.org/z/5oe34M731
>
>
> This patch actually seems quite nice. It does the thing I've always wanted but never gotten around to doing, which is actually permitting the return of non-movable/non-copyable types as long as the returns (or in your case, the variables) are correctly annotated with [[nrvo]].
>
> 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.
>
> 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.)
>
> –Arthur
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals