On Mon, Apr 30, 2018 at 09:11:07PM +0000, Gerald via Digitalmars-d wrote: [...] > So I'm curious, what's the consensus on auto?
Don't know what others think, but personally, it's one of the best things about D: all the safety of static typing, yet with the convenience of automatic type inference, so that I don't have to keep repeating myself. When I'm using chained range-based algorithms, I really do *not* want to have to name every intermediate type explicitly. That would be so cumbersome that the idiom would be essentially useless. Also, design by introspection. Dependence on explicit types is so last century. Design by introspection FTW! Decoupling your code from explicit types makes it more encapsulated, and gives you incentive to write more defensively, resulting in better, more change-resilient code. When an upstream library changes a return type, you can just recompile and go, rather than waste time patching the 150 different places where the explicit type was named. Let the machine do the work for you! As for ReturnType: I actually find it completely worthless. It adds needless template bloat, where typeof() (specifically, typeof(return)) would do just fine. And as for the documentation issue: either (1) the docs are b0rken and need to be rewritten because they didn't describe the returned type sufficiently well, in which case either the docs need to be fixed, or the library is poorly written and you should find another one; or (2) it is an indication that your code has extraneous dependencies on explicit return types and therefore is flaky and will break with the slightest upstream changes, in which case the code should be restructured and the needless assumptions / dependencies removed. T -- 2+2=4. 2*2=4. 2^2=4. Therefore, +, *, and ^ are the same operation.