hokein wrote: Thanks for the summary.
> We do not think a feature flag is a good fit. > > * Until clang 19 ships (in 6 months) we do not need to stabilize the feature > (but ofc we should avoid regressions, which we would not find if hidden > behind a flag), and the flag does not guarantee existing features are not > impacted. > I think this works fine with clang open-source release cycles (18 release was just cut, we have 6 months from now to polish this feature). However, this is not applicable for our internal case. At Google, we have used C++20 in production, and we have our own toolchain release cycles (which stay close to upstream main). Checking in an in-development C++20 feature without a proper safeguard poses risks to users (clang crashes, incorrect compilations, and other issues). So having a temporary flag is useful, it enables us to incrementally test and experiment it without compromising the experience for most users. > And if we break trunk, we revert, you get extra test cases... it's perfectly > fine We could revert the whole patch when things are broken (and it is what we usually do). But I'm not sure revert/reland a big patch back and forth is a good idea. This also brings a general question: what level of quality should we require from experimental features in HEAD? > We do that for about every feature that is not concept/module scale (and then > again, these things were tses), and this isn't big enough to warrant a novel > approach. Yeah, I agree that this is a narrow feature. Given that this feature is very late to the party, and C++20 has been used in some productions, I think it is probably reasonable to have a flag. > I still think we should land this soon and we can start a review whenever you > are ready. If you want to land it in an incomplete state, we just need to make sure we have a good collective understanding of the remaining work that would need to be done to bring the feature to completion (tests with fix me, issues, etc) +1, I think the current state should be good enough and ready for review. The remaining big piece (see the FIXME) is to implement the associated constraints (over.match.class.deduct#3.3). https://github.com/llvm/llvm-project/pull/77890 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
