[PATCH] D134453: Disambiguate type names when printing NTTP types

[David Blaikie via Phabricator via cfe-commits]

dblaikie added a comment.

In D134453#3875392 <https://reviews.llvm.org/D134453#3875392>, @erichkeane wrote:

> FWIW, i find the GCC diagnostics (and the application of this patch) to be much more clear/easy to read.  The pile of `{` and `}` don't really look useful/readable/meaningful to me, and leaves us ambiguous, so I'm in favor of this.

I'm not suggesting we go with anything ambiguous - so including the top level type (especially for `auto` template parameters where omitting it could be genuinely ambiguous, but even for non-`auto` where omitting the type would produce an invalid identifier, but not be ambiguous) seems like a good thing to me.

It's a question of whether we include the nested types, or the nested variable names, both, neither, or something else.

In D134453#3875538 <https://reviews.llvm.org/D134453#3875538>, @aaron.ballman wrote:

> In D134453#3872355 <https://reviews.llvm.org/D134453#3872355>, @dblaikie wrote:
>
>> But yeah, not sure/open to perspectives.
>>
>> @aaron.ballman - member names V type names V both?
>
> I think type names are really the only thing that will disambiguate the expressions in some circumstances. Consider the case where there are two unrelated classes both with the same member name (like `Person::name` and `Vehicle::name`) -- having: `S<Shape{.obj = {.name = "foo"}}>` would still leave the reader guessing as to what object is actually being created without having to go chase the information down themselves.

But the top level type is specified - that's an unambiguous identifier (`Shape`). I think there'd be cases where only using the type name (and not the member name) is ambiguous - probably more often. Like I have a struct with a couple of strings and a few ints. Including the names of the string type twice and the int type three times is probably not very informative - but including the member variable names is more likely to be informative to the user within the domain of the outer type information (this is what debuggers tend to do, for instance - print the member names, not their type names). We can do both, but that seems really verbose. Maybe that's the right thing though?

> That said, I am also curious to hear if @mizvekov has thoughts on this topic because he's been doing excellent work on template readability.




Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D134453/new/

https://reviews.llvm.org/D134453