I like std::take(). I use std::exchange(x, {}) quite a lot.

On 16/08/2022 00.05, Arthur O'Dwyer via Std-Proposals wrote:
> Right, `myobj = {};` usually does what you want; or if you follow my
> advice to "Make all constructors explicit," then `myobj =
> decltype(myobj){};` usually does what you want.
>
> There was a recent informal proposal for `std::take(x)`, being
> essentially a synonym for `std::exchange(x, {})`:
> https://lists.isocpp.org/std-proposals/2020/09/1900.php
> https://groups.google.com/a/isocpp.org/g/std-proposals/c/qDB0BG-GQqQ
>
> I don't think it was a good idea then, and I don't think it's a good
> idea in this incarnation either.
>
> my $.02,
> Arthur
>
>
> On Mon, Aug 15, 2022 at 2:08 PM Scott Michaud via Std-Proposals
> <std-proposals_at_[hidden]> wrote:
>
> I should note that a lot of classes can be reset just by
> move-assigning an instance of the class's new state by-value.
>
> MyClass one = MyClass(); // Intentionally constructing the verbose
> way.
> DisturbTheStateOf(one); // Get one into whatever state.
> one = MyClass(); // Pretty much resets one, albeit with some
> caveats (ex: if you have a no-move, no-copy type; must be
> extra-careful of the order of members when creating the class; etc.).
>
> On Sun, Aug 14, 2022 at 8:28 PM Greg McPherran via Std-Proposals
> <std-proposals_at_[hidden]> wrote:
>
> Hi Sebastian,
>
> >> What do you mean by "once-and-done"?
> Once a ctor is used, the ctor function is no longer available
> to be called for the existing instance. The re-init concept
> would be the same idea: Perhaps a syntax such as
> some_object_instance::(args) where args and overloads are the
> same as the ctor args and overloads.
>
> >> .. take the task of writing it over from you.
> Yes, this is my thought. I am requesting things in the
> language that I would find useful but I'll leave it to the
> language designers to see the value and determine the syntax.
> I simply wanted to place it on the table because I think they
> may be exciting. I will summarize again here:
>
>
> * Ctor-like re-init special functions that are not available
> as normal functions after init just as ctor is not
> available as a normal function on an object.
> * const after first init - useful for init'ing global
> objects that are intended to be constant but one would
> like the cnage to init them once and only once at runtime
> (startup).
> * class*pool* keyword or similar idea that causes the
> compiler to use an object pool for instances of the class.
>
>
> So these are all concepts and again I leave them for what they
> are worth. To me they have worth. If any of the language
> designers designers see value and would like to correspond,
> that is fine, but my goal here is to simply leave them on the
> table for the experts to decide if/how these concepts might be
> incorporated into the language.
>
> Thank You,
> Greg McPherran
>
>
> ------ Original Message ------
> From "Sebastian Wittmeier via Std-Proposals"
> <std-proposals_at_[hidden]>
> To "std-proposals_at_[hidden]"
> <std-proposals_at_[hidden]>
> Cc "Sebastian Wittmeier" <wittmeier_at_[hidden]>
> Date 2022-08-14 7:40:38 PM
> Subject Re: [std-proposals] Class Instance Re-Use/Re-Init
>
>> Dear Greg,
>>
>> standardization is done by a lot of people in their free time
>> or paid by their employers beside their normal work.
>>
>> So your task will be more of convincing people and putting
>> effort into your proposals (writing the paper, researching
>> motivations, opinions, solutions, previous efforts).
>>
>> "We all" are "C++ customers". This list will give you
>> feedback and guidance. The decisions are made by ISO groups
>> consisting of the same and other people according to your
>> written proposal.
>>
>> If you give good reasons, it could be that other people help
>> with your proposal or (in rare cases) even take the task of
>> writing it over from you.
>>
>> You quickly wrote about two ideas, but did not give further
>> details. It is quite difficult to understand, what you are
>> exactly *proposing* (as you wrote in your first message to
>> the list), how it would work in detail and what the
>> difference (and advantages) is to solutions already possible.
>>
>> For the class instace-re-use/re-init proposal:
>>
>> - The constructors are not doing the memory operations. This
>> comes before and depends:
>>
>> *automatic (local) variables
>>
>> * new
>>
>> * placement new
>>
>> * std::construct_at
>>
>> * std::allocator_traits::construct
>>
>> * std::unitialized_default/value_construct
>>
>> The current constructor is independent of those. It works
>> with all ways. It just fills the memory, it resides in.
>> Whether it was newly allocated or it is replacing existing
>> content. What would your special function do different than
>> an existing constructor, so that a new function is needed?
>>
>> - There are also move- and copy assignment operators as
>> special member functions, which reset an existing object
>> without destructing it first
>>
>> - What do you mean by "once-and-done"?
>>
>> - How and when would it be called? Manually? Or by the
>> language? In what cases?
>>
>> - Everybody is free to create reset()-like functions for
>> their classes. Would you make it mandatory? For all or
>> certain classes? Would there be a default implementation?
>> Which just destructs and constructs the object at the same place?
>>
>> const-after-first-init could be solved with a setter
>> member-function, which only accepts data, as long as the
>> object is not initialized yet. Or with std::optional again or
>> with factory functions. Or with views or with Facade patterns.
>>
>>
>> Best,
>>
>> Sebastian
>>
>>
>> -----Ursprüngliche Nachricht-----
>> *Von:* Greg McPherran via Std-Proposals
>> <std-proposals_at_[hidden]>
>> *Gesendet:* So 14.08.2022 23:17
>> *Betreff:* Re: [std-proposals] Class Instance Re-Use/Re-Init
>>
>> So, in summary, the two features that I am requesting as
>> a C++ customer are:
>>
>> * Ctor-like re-init once-and-done special functions
>> that are not available as normal functions after init
>> just as ctor is not available as a normal function on
>> an object.
>> * const after first init
>>
>> Thank You,
>> Greg McPherran
>>
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>
>