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

[Marc Mutz]

On Tuesday 22 March 2016 03:01:44 Stephen Kelly wrote:
> 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.

This is a general issue in C++ and should be solved generally:

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4035.pdf

Thanks,
Marc

-- 
Marc Mutz <marc.mutz at kdab.com> | Senior Software Engineer
KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company
Tel: +49-30-521325470
KDAB - The Qt Experts