Hacker News new | past | comments | ask | show | jobs | submit login

I initially disliked this also, but then I realized this is a natural extension of just programming generically almost all the time. You use the language to manage flow between types and to define types, but the types themselves aren't "binding" in a sense. If you use auto all the time but don't use templates, type deduction, and automatic type conversion, you're missing out on much of the language.

Auto forces you to think about the general relationships between types. In a sense, it really brings all of the elements of the language together.




In my example although auto was used, it was explicitly specified in the trailing return type that the function returned an int. This makes auto both needless and confusing in this instance, and should hardly be a recommendation!

You are right about the joys of auto with regard to template types and deduction but the implicit type conversion in C++ is a big danger; far better to be explicit about what a function is returning for the most part due to your inability to constrain the implicit conversions; it also helps with maintainability as you can read through small portions of a giant codebase without having to have a holistic overview of the entire system - you can treat each section in isolation because it is explicit in what it is returning, so you can make decisions as a maintainer based on the explicit information in front of you instead of the "it might be this or it might be that" scenario that auto (as a return type) offers.

(I'm not saying auto is bad, but should be used with caution for the return type of a function as it makes the code impossible to understand without an IDE - from looking at a diff between two files, how do I know what it is doing or make a fix under pressure?) Auto when used as a shortening of lengthy template iterator variables, then yes I heartily welcome them.


There is no maintainability problem if the general behavior is correct for all types that a statement can be composed of. You don't need an IDE, you just need a decent operating model of the nature of interactions between types.




Join us for AI Startup School this June 16-17 in San Francisco!

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: