mizvekov added a comment.
In D134453#3885423 <https://reviews.llvm.org/D134453#3885423>, @aaron.ballman
wrote:
> I can live with this approach if folks think it's the better way to go. But
> my concern still remains that the user has no idea what's being constructed
> by `{3}` or `{4}` without tracking down which constructor of `t1` is being
> called. Because of overloads, `std::initializer_list`, and conversion
> operators (and the fact that C++ initialization rules are a bit of a
> disaster), I think this can be unobvious sometimes without including type
> names. That said, after playing around a bit, I think those times might
> involve more contorted code than others are worried about, and so maybe it's
> not worth worrying about those cases. The fact that Clang is the only C++
> compiler that doesn't print full type information makes me wary though. My
> thinking is that it's always more frustrating to have not enough information
> in a diagnostic than too much information (both are problems in their own
> ways though).
I think the problem here is that since we don't have the as-written argument,
we just have the converted argument which is an APValue with the state of the
object.
I don't think we can in general, starting from the state, figure out which
constructor would produce that state.
So we might print it with a syntax as if the class was a simple pod type, even
though that might produce a completely different result if used in practice.
I don't think we can do much better without having the actual expression used.
That might be a point in favor of the designated-initializer style with the
field names, that should never produce the wrong result if copy-pasted back to
code.
> I can understand it being less readable for deep nesting situations, but I do
> not see why it would be prone to bad corner cases -- it's the most explicit
> form we can write (and matches the behavior of all other C++ compilers, from
> what we can tell).
The types of the fields might be internal, or otherwise too distant from user
code.
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
