Martin Sebor <mse...@gmail.com> writes: >>>>>> By way of a random example from genrecog.c: >>>>>> >>>>>> int_set::iterator end >>>>>> = std::set_union (trans1->labels.begin (), trans1->labels.end >>>>>> (), >>>>>> combined->begin (), combined->end (), >>>>>> next->begin ()); >>>>>> >>>>>> There is no immediate indication precisely what type int_set::iterator >>>>>> is. All we can tell is that that it's some sort of an iterator, and >>>>>> that should be good enough. It lets us (even forces us to) write code >>>>>> that satisfies the requirements of the abstraction (whatever it happens >>>>>> to be), and avoid tying it closely to the implementation. That's >>>>>> a good thing. >>>> >>>> Do you mean that this example should or shouldn't use "auto"? >>>> Iterators are included in the list above, so the idea was that using >>>> "auto" would be the recommended style here. >>> >>> I meant it as a general example where the exact type isn't (and isn't >>> supposed to be) apparent to the caller because it's an implementation >>> detail. >> >> But like I say, the proposal was that this example should use "auto", >> and it sounds like you might agree. In that case I don't think the >> example really helps make the decision about whether the coding >> standards are useful or not. >> >> Do you have other examples that you think would be better written >> using "auto" that aren't covered by the list, and aren't covered >> by Jason's point about template-dependent types? > > I think it applies any time mentioning the exact type isn't > necessary, not just because it might introduce a dependency on > details that the code doesn't need, but also because it's more > verbose than the alternative. The for range loop mentioned > upthread is an example. > > But auto is just one of a number of new core language features > new in C++. Unlike some other C++ features(*), I don't think > it's easily misused, at least not to such an extent to justify > adding a guideline for us to use safely, consistently, or simply > in good taste.
I agree a guideline like that would be pointless. It'd be like saying "be good". :-) But the idea with the patch was instead to have conventions that use objective conditions. (The rationale was more subjective of course.) > Martin > > [*] I could see value in guidelines around rvalue references > or deleted and defaulted functions, for instance, since those > are easily used in dangerous ways. > > PS Herb Sutter has a nice article (as usual) where he summarizes > commonly raised concerns with auto and his thoughts on them: > https://herbsutter.com/2013/08/12/gotw-94-solution-aaa-style-almost-always-auto/ Almost always using "auto" seems a bit drastic when we're starting with a codebase that doesn't use "auto" at all. TBH I don't find the argument in that article convincing, especially the part about types often being implicit within expressions. E.g. it's true that: if( find(begin(c), end(c), v) == end(c) ) c.emplace_back(v); assert( !c.empty() ); is readable without having any explicit types. But it doesn't follow that larger blocks of code are just readable without having explicit types. That would be like saying that GCC's 1000-line functions are just as readable as small functions, since each statement is readable in isolation. The article seems to be concentrating on examples that are likely to crop up in templatised library code rather than in (say) IL processing. E.g.: take: auto size = compute_objsize (ref, ostype, pdecl, poff); Is that size a tree, some form of wide_int, or a plain HWI? The answer decides what you can do with the size. Using auto here forces you to look at the prototype of compute_objsize (which eventually might itself return "auto" on the AAA principle), or look around to see how "size" is used in practice. That's not likely to confuse the person writing the code. But: tree size = compute_objsize (ref, ostype, pdecl, poff); either makes life easier for whoever comes next, or doesn't make any difference to them either way. And that's true for longer type names too. Like Jason says, the default position if we don't add any guidelines is that whether "auto" is appropriate is a question for code review. Maybe some reviewers would accept patches that follow the "almost always auto" principle. Others probably would probably reject the patches and ask for more explicit types to be added. Others might accept something in between. If we don't add any guidelines, that would be the review process operating correctly. Thanks, Richard
