Hans Åberg <[email protected]> writes: >> On 7 Jul 2018, at 10:04, David Kastrup <[email protected]> wrote: >> >> Hans Åberg <[email protected]> writes: >> >>> The idea is to do it all now, then the change is automatic and the old >>> code can just be removed at some point in time, but you would need a >>> compiler that can do C++17, too. >> >> The whole point is that we do not want to rely on C++17 now and don't >> want to maintain a full reimplementation of a C++17 feature until we do >> when that feature is used only once and in a minor manner. The fallover >> strategy for it becoming available is not really of relevance for that >> call, but an automatic fallover would mean that we have dormant untested >> code that becomes active at different points of time for different >> people. > > The first step would probably to switch to a later compiler with a > flag for an older C++ version. Then one can test later C++ versions in > independent builds.
We are not really sticking with older language versions as an intellectual exercise but in order to stay with a least common denominator of actually employed compilers. Going to the bleeding edge, even with compatibility flags, when the main distributions and/or our users/integrators aren't there yet is not quite representative. "I cannot reproduce your problem" is something I want to avoid. I think we are at a stage where C++11 is ok to demand, C++14 does not bring a whole lot to the table, and C++17 is too early yet. We had some fallout when I used C++08 overload resolution rules for dealing with inherited acknowledgers and it turned out Clang++ was buggy in that regard. In that case, I decided not to dial back the refactoring because it would have been a lot of work and the result would have been considerably more ugly, but if we had caught that early on, the decision might have been different. Also Clang++ is kind of low priority since none of our official binaries are compiled in that manner and it's not clear there is a two-digit number of users/integrators working with a Clang++/LilyPond setup. -- David Kastrup _______________________________________________ lilypond-devel mailing list [email protected] https://lists.gnu.org/mailman/listinfo/lilypond-devel
