On Tue, Mar 15, 2022 at 06:29:50PM +0100, Paolo Bonzini wrote: > On 3/15/22 15:24, Peter Maydell wrote: > > On Tue, 15 Mar 2022 at 14:09, Stefan Hajnoczi <stefa...@redhat.com> wrote: > > > Also, once C++ is available people will > > > start submitting C++ patches simply because they are more comfortable > > > with C++ (especially one-time/infrequent contributors). > > > > This to my mind is the major argument against using C++ > > for coroutines... > > I agree on the need for a policy, but _what_ C++ are they going to be > contributing that we should be scared of? We're talking about: > > * major features contributed by one-time/infrequent participants (which is > already a once-in-a-year thing or so, at least for me) > > * ... in an area where there are no examples of using C++ in the tree (or > presumably the maintainer would be comfortable reviewing it) > > * ... but yet C++ offer killer features (right now there's only C++ > coroutines and fpu/)
You are assuming people only choose C++ only when it offers features not available in C. I think they might simply be more comfortable in C++. In other words, if an existing file is compiled using a C++ compiler or they are adding a new file, they don't need a reason to use C++, they can just use it. You can define rules and a way to enforce a subset of C++, but I think over time the code will be C++. A policy that is complicated discourages contributors. For these reasons I think that if code runs through a C++ compiler we should just allow C++. Either way, it will take time but that way no one will feel betrayed when C++ creeps in. That said, I hope we find an option that doesn't involve C++. Stefan
signature.asc
Description: PGP signature
