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

[Julien Blanc]

Le samedi 05 décembre 2015 à 12:08 +0000, Bubke Marco a écrit :

> >
> >> - template code (esp., but not necessarily only, when the type name
> >> would require the use of 'typename')
> >
> > This is the one i’m not at ease with. Template code tends to be
> > difficult to read, partly *because* there’s no type information. For
> > readability concerns, i would prefer a local typedef named by the
> > concept. Yes, that makes it two lines instead of one, but i think that’s
> > one case where hinting the reader with a well-chosen type name makes a
> > lot of sense.
> 
> Most typedefs I have seen was about hiding pointer or container types like CursorPointer or Cursors. But is CursorPointer a unique pointer,  a shared pointer and which flavor is it. Cursors is the same because it could be std::vector or QList. Some would hide a dictionary behind this name. So the typedef can be misleading. In that case I prefer auto. 
> 
> std::shared<Cursor> cursorPointer = document.cursorAtPostion(46);
> 
> CursorPointer cursorPointer = document.cursorAtPostion(46);
> 
> auto cursorPointer = document.cursorAtPostion(46);
> 
> I prefer the last but we need good tooling to show the type. It would be nice to have much more information like size,  is it movable or copyable. It is not only the type and we can provide that information. 

My understanding of Marc’s proposal was that it was more for the
following case :

    template<typename List> void algorithm(List& input)
    {
        typename List::value_type& first = input.front();
        ...
    }

replaced by :
    template<typename List> void algorithm(List& input)
    {
        auto& first = input.front();
        ...
    }

whereas i prefer 
    template<typename List> void algorithm(List& input)
    {
        typedef typename List::value_type Serializable;
        // there are some requirements on List : item_type must be
        // Serializable : now i can look the doc to see what a
        // Serializable is
        Serializable& first = input.front(); 
        // i know what to expect from first, which methods i can call
        ...
    }

I think the latter improves readability over the two others, because it
just gives more information to the reader. And this information is
currently *not* given by the type system, because concepts do not exists
in the type system yet. No tooling will ever give you a type information
here : it depends on the template instanciation.

Regards,

Julien Blanc