higher-performance wrote:
@martinboehme Could you explain how that is any different from this?
```
#include <string>
#include <vector>
bool TryInsert(std::vector<std::string>& v, std::string&& s) {
if (some_condition()) { return false; }
v.push_back(std::move(s));
return true;
}
std::string foo(std::vector<std::string>& v, std::string&& s) {
if (!TryInsert(v, std::move(s))) {
return std::move(s); // warning: 's' used after it was moved
[bugprone-use-after-move]
}
return {};
}
```
It seems to me the crux of your argument...
> sooner or later someone is going to ~configure an invalidation function~
> _compose an outer function_ that does return a value, will use that value in
> an expression, and be mightily confused about why the check doesn't
> understand when the invalidation happens.
...applies ~verbatim to situations with `std::move` and `std::forward` too, no?
---
> I realize this is often not an issue in practice
This is important, and has been our guiding principle here. The reality is this
check (and the typical tidy in general) has always had rough edges and been
inherently limited in what it can do. Tidies are improved incrementally after
actual circumstances arise commonly enough to warrant it. (See the
`try_emplace` hack in this tidy, for example.) They are never going to be
perfect, or even as precise as a compiler -- nor should they be expected to be.
Perfect is the enemy of good here.
---
All that said, though, I'm not really opposing you: if you'd like to make the
check more precise, or rename it more accurately, and others are on board -- I
have no particular opposition. I've done what I can to improve it so far, and
I'll be happy to see contributors improve the check further.
https://github.com/llvm/llvm-project/pull/170346
_______________________________________________
cfe-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
