Thiago Macieira wrote: > On sábado, 19 de março de 2016 19:02:08 GMT Stephen Kelly wrote:
>> Hi, >> >> In case you missed it, I wrote an auto-modernizer >> >> https://steveire.wordpress.com/2016/03/19/aaargh >> >> It is not quite AAA, as it doesn't convert >> >> QString s; >> >> into >> >> auto s = QString(); > > Thanks Stephen > > The post is very informative. Thanks for the tool too. Great, thanks! > But if the code above were auto, s would be a QStringArgBuilder. And if > you had later: > > someFunction(s.arg(M_PI)); > > We'd have a behaviour change... Note that this is nothing to do with the tool, so I've broken out a different thread. 3rd party code is already using auto s = tr("%1 (%2)").arg(someString()).arg(42); someFunction(s.arg(M_PI)); so your proposal is not as source compatible as you think. It is about as source compatible as QStringBuilder is when introduced to code which already uses auto. QStringBuilder is not on-by-default for operator+, or wasn't the last I checked, so a user could enable it today for a codebase which already uses auto extensively with a result of strange runtime behavior. Presumably your proposal is either Qt6 material or something to be enabled by the user with a compile definition similar to QStringBuilder. Problems like you describe could similarly be found with a clazy check. At least for Qt 6 you could consider what kind of (clang based) tooling to make available for 5-6 ports to make this kind of change more visible to people porting. Thanks, Steve.
_______________________________________________ Development mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/development
