Quuxplusone added a comment.
> Concretely, I think we could warn if, during template instantiation from a
> type-dependent initializer, we select the copy deduction candidate and there
> was another viable candidate (the `optional o(x)` case, the `tuple
> t{args...}` case, etc), maybe under a new `-Wctad-unwrap` or similar.
The trick is that you have to give the warning //even when the copy deduction
candidate is not selected// — e.g. `tuple t{args...}` when `args...` is not a
1-parameter pack //right now// but if it might turn out to be a 1-parameter
pack at "production time" (after the library has reached the customer).
> I don't see a good general way to catch and warn on bugs like `vector<string>
> v("foo", "bar")`
You mean `vector v("foo", "bar")`. Without CTAD — `vector<string> v("foo",
"bar")` — there's no bug; the line of code simply doesn't compile, that's all.
What CTAD adds is the possibility for the line to quietly //compile into the
wrong thing//.
> (this problem isn't really specific to CTAD)
Maybe not, but it's certainly //correlated//, right?
> but we could certainly add some special-case heuristics to detect cases where
> a pair of string literals is passed to a constructor of a container-like type
> (for example, we could check whether the constructor looks like it can be
> called with arbitrary iterators as arguments, the class also has an
> `initializer_list<T>` constructor where a string literal can be implicitly
> converted to `T`, and the class has begin and end member functions).
For my own use-cases, I will continue to want a 100% comprehensive `-Wctad`.
All these "heuristics" you're proposing seem very ad-hoc, and make a lot of
work for the compiler vendor, and seem complicated enough that I would still
worry about bugs slipping through the cracks. Whereas, if the user can simply
100% outlaw CTAD, then they don't ever have to worry.
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D56731/new/
https://reviews.llvm.org/D56731
_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
