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, {})`:

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,

On Mon, Aug 15, 2022 at 2:08 PM Scott Michaud via Std-Proposals <std-proposals@lists.isocpp.org> 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@lists.isocpp.org> 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@lists.isocpp.org>
Cc "Sebastian Wittmeier" <wittmeier@projectalpha.org>
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.




-----Ursprüngliche Nachricht-----
Von: Greg McPherran via Std-Proposals <std-proposals@lists.isocpp.org>
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 mailing list