On Tue, 12 Mar 2024 at 14:50, Andrei Grosu <andrei_dg_at_[hidden]> wrote:
>
> Well move semantics is an opt-in feature, albeit at a different level. I’m not comparing apples to apples, but it’s not like you are forced to implement move semantics everywhere if you compile with c++>=11
>
> I now understand that the gripe seems to be that this is something that , if not required, must be disabled at compile time and this is an issue.
>
> I guess the problem is that the standard is for ‘everyone’ whatever that might mean, and all features should run everywhere. Well, in that case, what about atomic<T> on platforms that don’t support it and turn it into a mutex-wrapped value …?
> We have a std::atomic_is_lock_free which , in my opinion, is a kind of feature gating: if the implementation of atomic<T> is not lock free (ie just syntactic sugar over a mutex or something) you can tell. Again, not apples to apples but frankly it is confusing from a language design pov…

That comparison is like apples to poems.


>
> On Tue, Mar 12, 2024, at 16:29, Jonathan Wakely wrote:
> > On Tue, 12 Mar 2024 at 14:12, Andrei Grosu via Std-Proposals
> > <std-proposals_at_[hidden]> wrote:
> >> I understand and appreciate all the valid concerns, I agree that , in general, it would create problems, thus it could be a opt-in feature of the language ( like many others) for projects and environemnts where those concerns are not valid.
> >
> > Which ones? There are no opt-in features in the C++ standard.