[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>
wrote:
> > 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