[Development] RFC: more liberal 'auto' rules?

Thiago Macieira thiago.macieira at intel.com
Thu Dec 3 23:14:19 CET 2015

On Thursday 03 December 2015 21:15:42 Bubke Marco wrote:
> On December 3, 2015 19:06:17 Thiago Macieira <thiago.macieira at intel.com> 
> > On Thursday 03 December 2015 19:49:46 Marc Mutz wrote:
> >> The remainder of the C++ world is moving towards an "always auto" scheme.
> >> We don't need to go there, but I'd at least like to propose, for new
> >> code and> 
> >> as a drive-by, the *required* use of auto for:
> > The remainder of the C++ world is no indication for us.
> Actually I think it is. If Qt is to different we loosing mind share.

That depends on how big the remainder is. I argue that we're relevant enough 
that our own direction is big enough to be of relevance.

For example, we don't use exceptions and underscores.

> > Also remember that, for us, the source code is a product. We need to have
> > 
> > readable source code, so we have two ground rules that must be respected:
> >  1) the use of auto must make the code more readable, not less
> >  2) Qt Creator must be able to parse and deduce the correct type
> They Clang code model is doing it already and we working hard on building up
> a infrastructure on ╚Ťop of clang to exchange the old code model with the
> new clang version completely.
> > #2 is, of course, a transient issue, because Creator will get better over
> > time.

Good to know!

And since we're talking about it... when will Creator get support for 
concepts? :-P

That way, even in template code, it will be able to complete some things that 
the concept guarantees. Example:

template <typename T> concept bool IsNullable()
	return requires(T type) { 
		{type.isNull()} -> bool; 

template <IsNullable T> bool isNull(T t)
	return t.		// <--- should offer "isNull" here

Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center

More information about the Development mailing list