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
>