What you are doing is way too complicated for what is actually required.

std::factory, std::elide, std::whatever_indirect_method - It is trying to avoid a core language change by wrapping it up in magical standard library feature, that requires a secret vendor core language feature to implement.
It is not ergonomic and doesn't end up helping as it should. If it requires a core language, add an explicit one that adds consistent well-defined behavior, and not one of "does this work on this compiler?"

return slot, or std::return_slot - This is dead on arrival. It is semantically insufficient, it is not coherent within the language structure, and it is unimplementable.
The function signature isn't just for show, it conveys information as to how a function works. And the return statement doesn't tell not only the type, but practical information regarding "is this returned in a register? Or how much space do I need to reserve on the stack to receive the returned value before making the call". If you change that to "void", there won't be a "return" anything since the caller couldn't have known what space to reserve (much else be able to know what to do with it). Memory is not magic, you can't just express an idea in the function and expect it to be implementable.
If you put the return type back in, that won't fix the problem either. Remember there's a return statement that will exists in the language. First there's the problem of having to instantiate objects in memory manually, which is error prone. Second if you use it to instantiate an object manually it will then be clobbered by your return statement, there's no way for a compiler to track the lifetime of the object, there's no way to deal with it, it is inconsistent with the C/C++ language model.


I don't have a single doubt in my mind how this is supposed to work.
Right now, the language "allows" for copy elision of named variables, if the compiler can decide to do it or not to do it (since it is not possible in every case).
What you need is to add additional rules that would guarantee copy elision of named variables under certain conditions.
And the condition that seems to best maximize this is, "copy elision of a named variable is guaranteed if its lifetime does not overlap in any scope with another object that could also possibly be returned".

It is a simple sentence to change in the core language, it allows you to do everything you want in all circumstances that are possible, you don't need to write code differently, it doesn't do anything that the compiler isn't already allowed to do (but decides not to), you don't need to add a new library features or functions or keywords or hoops to jump, no gotchas, you can't do it wrong, you are able to express intent in a coherent manner and allow the compiler to do its job,
It always works and everything benefits regardless of it being immovable/uncopiable or otherwise. That's it, you don't need anything else.

The solution has to be this and nothing else.



-----Original Message-----
From: Std-Proposals <std-proposals-bounces_at_lists.isocpp.org> On Behalf Of Frederick Virchanza Gotham via Std-Proposals
Sent: Monday, May 27, 2024 22:57
To: std-proposals_at_[hidden]rg
Cc: Frederick Virchanza Gotham <cauldwell.thomas_at_[hidden]l.com>
Subject: Re: [std-proposals] std::elide

On Mon, May 27, 2024 at 9:48 PM Lorand Szollosi wrote:
>
> void Func(T* t) /* here, *t is not yet constructed */ {
> new(t) T();
> doSomethingWithT(t);
> }
>
> Then:
>
> template<typename R, typename... Params> consteval auto nrvo( void
> (*const arg)(R*, Params...) ) -> R(*)(Params...);
>
> Usage is the same. But then, it's very similar to std::factory.


Yeah that would work too. In fact, that's how compilers do it on 9 out of 10 platforms, as described in this old paper:

    http://www.virjacode.com/papers/paper_nrvo_latest.pdf

But the reason I wanted to have "std::return_slot" instead of passing a pointer as the first argument to the function, is that on 4 platforms, they don't pass the return slot in the first parameter.
Those 4 platforms are: 64-Bit ARM, HPPA, m68k, sh4. This is discussed on Page 4 of the above paper.

If we were to have "std::return_slot" instead of putting the pointer in the first parameter, it would accommodate those 4 platforms.
--
Std-Proposals mailing list
Std-Proposals_at_[hidden]
https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals