auto in library functions

Andrej Mitrovic andrej.mitrovich at gmail.com
Sun Dec 23 14:41:45 PST 2012


On 12/23/12, Jonathan M Davis <jmdavisProg at gmx.com> wrote:
> It makes refactoring the code much easier and reduces code breakage
> due to type changes.

I don't buy that. If a type of a variable changes don't you want to
*know* the new type of the variable? If between two commits you have:

auto x = z;

and then:

auto x = z;

How will you know that x has become something completely different?
You would have to know what 'z' is, and it's hard to know that if
you're using auto inference everywhere. I personally only use auto
when necessary, and that's when: 1) using templates, 2) using
voldemort types and 3) for quick hash lookups via "if (auto x = key in
hash) { }".

Furthermore not using auto helps you visually detect signed/unsigned
bugs. If you have:

auto x = z;
if (x < 0) { }

You better declare a type for x because if you leave it unsigned
you'll never notice if something is wrong. Btw Walter denied a pull
for comparing `unsigned < 0`, so you're left on your own to care about
these issues, the compiler wont help out.

You say auto helps with refactoring. I say not using it helps with
catching bugs. It comes down to a question of what you value more,
your time while coding, or your time while debugging.


More information about the Digitalmars-d mailing list