On Sunday, 23 December 2012 at 22:41:56 UTC, Andrej Mitrovic wrote:
> 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.

Or even just reading code, which is what programmers spend most of their time doing.

When reading code, you want things to be both clear and succinct. With long (or inexpressible) type names, using auto makes the code more succinct, but for simple types like int, bool, or structs/classes with short names, it's far more clear to just use the type name.

I don't buy the refactoring argument. Refactoring is rare. Refactoring gains are not worth compromising readability.

On 12/23/12 9:13 PM, Peter Alexander wrote:
> On Sunday, 23 December 2012 at 22:41:56 UTC, Andrej Mitrovic wrote:
>> 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.
>
> Or even just reading code, which is what programmers spend most of their
> time doing.
>
> When reading code, you want things to be both clear and succinct. With
> long (or inexpressible) type names, using auto makes the code more
> succinct, but for simple types like int, bool, or structs/classes with
> short names, it's far more clear to just use the type name.
>
> I don't buy the refactoring argument. Refactoring is rare.

In the words of Dwight Schrute: false.

Andrei

> If a type of a variable changes don't you want to *know* the new type of the variable?


Actually, not at all.


Consider this C++ code as an example:


std::vector<int> foo;

template<class T>
void process(T &data) { ... }

int test()
{
	auto copy = foo;
	process(copy);
	if (copy.size() == foo.size())
		foo = copy;
	return copy.size();
}



The word 'auto' protects against changes to the type of 'foo' (say, for example, if it was alter changed into std::deque).


No need to explicitly state the type of 'copy' anywhere.

On 2012-12-23 23:16, Jonathan M Davis wrote:

> But with return types, it affects the documentation and people's ability to
> figure out what a function does, so as useful as auto return types can be, they
> come with a definite cost and should be avoided if they're not needed.

The compiler should be able to replace "auto" with the actual type when generating documentation.

-- 
/Jacob Carlborg

On Monday, December 24, 2012 12:07:53 Jacob Carlborg wrote:
> On 2012-12-23 23:16, Jonathan M Davis wrote:
> > But with return types, it affects the documentation and people's ability
> > to
> > figure out what a function does, so as useful as auto return types can be,
> > they come with a definite cost and should be avoided if they're not
> > needed.
> The compiler should be able to replace "auto" with the actual type when generating documentation.

That would be horrible. Do you remember what std.algorithm looked like before we were able to put auto in the documentation? It scared most everyone who looked at it. We don't _want_ the actual return type in the docs. auto  return types makes std.algorithm digestible. And with some functions, they literally return completely different types depending on their arguments, making it impossible for the compiler to pick anything for the return type.

- Jonathan M Davis

On 2012-12-24 16:09, Jonathan M Davis wrote:

> That would be horrible. Do you remember what std.algorithm looked like before
> we were able to put auto in the documentation? It scared most everyone who
> looked at it. We don't _want_ the actual return type in the docs. auto  return
> types makes std.algorithm digestible.

Right. This is what I still don't like about ranges, there is no type/interface to name them. It would be so nice if a struct could implement an interface or similar.

> And with some functions, they literally
> return completely different types depending on their arguments, making it
> impossible for the compiler to pick anything for the return type.

Hmm, right, that can be a problem.

-- 
/Jacob Carlborg