Yes, topic split would be nice.
one might actually not care about the concrete type of (e.g.) a sequence (a vector, list or something custom? nah, that the same to me)
To some extent, Java goes this way with its
List<T> interface that covers any kind of sequence: vectors, lists, ... And while it's nice that we have at least one abstraction at all -- because unlike templates, Java's generics are not useful for static polymorphism -- some operations like random access need not be efficient at all. So, harmless code such as
for (int i = 0; i < list.size(); ++i) {
doSomething(list.get(i));
useIndex(i);
}
can be extremely inefficient. Java is excellent at hiding such pitfalls. But as you say, there are cases where I'm really not interested and just want a collection in its literal sense. My Aurora.Range module was an attempt in that direction, but I eventually removed ranges from the library because they were not mature enough.
I have experienced this effect even more in dynamic languages (e.g. Lua, PHP, JavaScript), where you're given just 1 or 2 basic data structures (sequences and maps), and surprisingly, it's really enough.
Yes, but this is not inherent to type inference: you can have exactly the same issues with "regular" changes (improving an implementation yet breaking a contract; change the semantics of an existing type; ...). So I wouldn't held this against `auto` but rather against a bad developer. 
It's not a problem of the developer, because type inference introduces a source of error that wouldn't be there without it. This doesn't only apply to
auto/decltype, but also function templates that infer their parameter types from the arguments.
struct GameObject
{
auto getHealth()
{
return 16 * mHullStrength + 4 * mArmor;
}
int mHullStrength, mArmor;
};
// elsewhere
sf::Shader shader = ...;
shader.setUniform("health", obj.getHealth()); // int
Tweaking the parameter:
auto getHealth()
{
return 16 * mHullStrength + 4.2 * mArmor;
}
...
shader.setUniform("health", obj.getHealth()); // double -> BAM
Of course you can say that's a bad developer, but the fact is that an explicit return type (int) would have prevented this error. The developer would have gotten a warning that he's trying to convert double to int, and by being aware that he's changing the type, he will check if the client code needs to be adapted.
And this is only a simple example; when types are inferred across a deeper call hierarchies, code becomes even more difficult to track.
you can already annotate, using `auto`, whether a variable is a value, a pointer or a reference (or constant):
for (auto v : seq)
for (auto* p : seq)
for (auto& r : seq)
Yes, but that's far from enough. It only expresses what kind of indirection we use, we still know nothing about the type. Type inference currently can't meaningfully express concepts like "container" or "number".
auto/decltype cannot do it at all, for inferred template parameters, one has to resort to ugly SFINAE to come even close.
That being said, I join you when you say that a wall of auto is harmful. But doesn't this kind of code usually suffers from other issues as well (such as functions being too long and obscure code patterns being used)?
Possibly, such phenomenons may just be a result of inexperienced developers. I have the expression that many people who learn about C++11/14 want to be part of the cool kids and make excessive and unquestioned use of new language features, without noticing that something being modern alone doesn't make code automagically better. This can also be seen by projects that advertise themselves already as "C++14 library" before they even mention what they're about
But it's a really welcome variation to the massive amount of medieval, backwards-oriented C-with-classes code written by "I wrote this successful C++ software in the 90s so don't tell me anything" dogmatists
