ckandeler wrote: > In the expression-statement case, the expression isn't moving to a new > location, and the variable name is only mentioned in > one place. In essence, the refactoring amounts to prepending `auto > placeholder = ` to the expression. Given that you're > going to be (very likely) renaming `placeholder` anyways, does this really > add anything meaningful over just typing `auto > VariableNameYouWant = ` "manually"?
My thinking was that because the expression is assignable and it's not clearly pointless to do so, the tweak should be available (plus it still saves some keystrokes). My concrete motivation was due to user requests on the client side, e.g.: https://bugreports.qt.io/browse/QTCREATORBUG-9363 https://bugreports.qt.io/browse/QTCREATORBUG-9578 Maybe some developers have the habit of writing just the rhs of an init statement and then let tooling insert the lhs? It's possible, I suppose. E.g. if the return type is complex and you want to have it spelt out in the declaration (as per the project's coding conventions), then you could apply this tweak and then the ExpandDeducedType one. In general, I'm not a big fan of going out of my way to prevent users from doing something. And once you start deliberating about degrees of usefulness, you quickly run into problems deciding where to draw the line. https://github.com/llvm/llvm-project/pull/112525 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
