[Development] Source compatibility for third parties using auto (Was: What qtbase looks like with extensive use of auto)

[Stephen Kelly]

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.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20160322/f1153540/attachment.html>