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
_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
