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