That example isn't what OP is talking about, because it's obvious what the type of p is because it's on the same line:

    auto p = std::make_shared<T>();

whereas the following isn't clear and isn't necessarily correct without looking up what the return type of foo() actually is:

    auto p = foo();

I'll agree that your second example is less readable than the first..

This could be mitigated with the name of foo() being more descriptive.

If the return type is particularly wordy, auto could still be appropriate.

> This could be mitigated with the name of foo() being more descriptive.

welcome back Hungarian notation

lpwszThanks.

In seriousness, no, that's not what I'm suggesting, and I find it an unusual thing to read from my comment. I'm saying a descriptive name for foo() can give you a hint about what the type is, even if it doesn't literally and directly tell you what the type is.

auto conn = createConnection();

What does this have to do with hungarian notation?

You’re thinking of it wrong.

This works better:

auto uasStudents = getClassList()

In this case, “uas” prefix standing for an unsafe array of strings.

Then say you validate the list

auto sasStudents = validate(uasStudents)

(Now it’s a safe array of students!)

I feel like I’m missing a joke.

Alone this looks like a reasonable use of auto. In a real codebase, there may be two (or twenty) different connection-like things, multiple of which may be reasonably to call in this context.

The "Hungarian notation" comment is correct - it's not strictly Hungarian notation, but annotating function (or variable) names when the language has a type system representing this same information is the same idea with the same problems as Hungarian notation.

this is required for writing generic code when the function may return different types

Lambdas I would agree with and iterators, but in many other situations, e.g. templated collections it's easy enough to make a descriptive typedef.

And... I have seen this in the wild: 'auto isFalse = true;'