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
