dblaikie added a comment.
> In terms of next steps, I think we should try to see if there's a "clear" > path forward in terms of printing the types vs not printing the types. If we > find one, then great, we go that way. But if we don't seem to have a clear > path forward (relatively quickly; I don't think we want to drag this > discussion on for months trying to find the perfect answer), then I think I'm > fine with the patch as-is. It fixes the issue of `t<{}>` (with empty braces > specifically) while retaining the status quo in other areas, but still > exposes useful functionality through the additional printing policy. Does > that sound reasonable? If you reckon (1) is better overall anyway - happy enough to defer to your opinion there and go with that, skip/omit the printing policy. I think the policy is like adding off-by-default warnings, and supporting a use case (using the string name for reflection when we'd recommend the AST) I don't think we want to encourage/support. Admittedly going with (1) means that @DoDoENT's use case will then work, until/unless we come back around and make more strategic use of type names in this printing in the future to bring down the verbosity - so I'd still discourage that use case & warn that this isn't a guarantee that all type names will be included going forward. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D134453/new/ https://reviews.llvm.org/D134453 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits