Re: Is C++ becoming too large and complex?
No madness, just perhaps a misunderstanding of what a declaration is for, and an attempt to misuse a keyword for its side-effects.
Because that is the whole point of auto - deduction of a type from an initializer. It is for exactly that purpose - to allow you not to be specific.
You can't keep hand-waving all the way to the the metal. At some point, you have to be specific, and for a variety of reasons, allocated class member types are one of those places.
Incidentally, you are allowed to use auto to declare a field of a class/struct, but only where that field is both static and const (and the initializer is a constexpr or literal) static const fields are special, though, allocated and assigned just once and shared by every instance (sometimes they don't even get allocated unless your code tries to get the field's address). This single point of initialisation may give you an idea why they can easily be allowed to use auto, while class-members are not... hint: consider how you'd declare a constructor that sets your Fred::x field.
Even if it didn't cause problems for code generation, your desired solution would only work for fields that have a default initializer, and thus it is only half a solution for the legitimate requirement of needing a field that can always contain the return-value of a given function. Luckily, the people standardising the language did consider this, and so if you need a field type that always matches the return type of a function, you should be using decltype(), which can be used regardless of initialization status. (auto can be seen as a special-case of decltype() for use when declaring variables and constants)
struct Fred { decltype("gotcha") x; decltype(foo()) y = foo(); };
... and this syntax also allows you to write a constructor, or any other function, whose argument type will match the return-type of a function, or match the type of any other declared constant.
