Endilll wrote: > Given the concerns raised here, it might make sense to put this change on > hold, do a few more similar experiments for other parts of C++, and see what > sort of principled design approach makes sense to take here.
It's not clear to me what do we want to clarify or try out before going forward with this PR. I moved concepts out of `Sema` in #92672, and that also went well in terms of resistance I felt while trying to get declarations out of `Sema`. We need to start somewhere, and I believe concepts and coroutines are the right first steps. Alternative is to come up with some kind of a grand plan for core C and C++ parts (Expr, ExprCXX, Decl, DeclCXX, etc.), but prior discussions on the topic suggested that it's not feasible at this point. > My current thinking (which could be off-base!) is that for language features > strongly tied to language semantics (like coroutines), if we do split them > then it probably makes sense to split those off in a language-based approach > (getSema().CXX().Coroutines().whatever) whereas more language-agnostic > concepts (like constant expression evaluation) might make sense to split off > into their own component whose language-specific behavior can be controlled > by a traits object of some kind (getSema().ConstExpr<SemaCXX>().whatever). Whatever shape `Sema` is going to take in the future, splitting `Sema` into a flat list of components moves us forward, because merging components back into bigger components is trivial compared to splitting them up. One of the primary goals of this effort is not as much transforming `Sema` according to some vision, as it is highlighting and learning how various parts of it are connected. That should make our future design decisions more informed. https://github.com/llvm/llvm-project/pull/92645 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
