On Sun, Feb 12, 2023 at 4:06 PM Frederick Virchanza Gotham via
Std-Proposals <std-proposals_at_[hidden]> wrote:

> On Thu, Feb 2, 2023 at 5:49 PM Thiago Macieira wrote:
> >
> > You've mostly implemented this already as library solutions.
> >
> > So please explain why you think this should be a core language change.
> What
> > can the core language do better than a library solution could?
>
>
> I haven't got a library solution. Needing to add 'atomic_flag' objects
> to your classes and functions, and then manipulating them as
> appropriate, isn't simple [...]
> I'll try to explain what I mean here by making a comparison with
> another of C++'s features. In C++, we can have a static object inside
> a function, and even if our program is multi-threaded, the
> aforementioned static object will only ever be constructed once (and
> the other concurrent threads will wait for it to be
> fully-constructed). So this means I can write really simple code like
> the following:
>
> void Func(int const arg)
> {
> static std::string str = std::to_string(arg);
>

Right. And if instead of being a local variable, `str` were a member
variable, then you would have to do this instead:

    struct Widget {
        std::once_flag f_;
        std::string str_;
    };
    void Widget::func(int arg) {
        std::call_once(f_, [&]() { str_ = std::to_string(arg); });
        // the rest of the function goes here
    }

That is, we have precedent for "simple case gets core-language support,
member-variable case gets a library solution."
So, I again encourage you to write up exactly what your library solution
would *do*. Once we know what it does, we can start worrying about whether
it ought to have a core-language syntax for the simple cases or not.

–Arthur