What are some reasonable stylistic limits on type inference?

Question

C++0x adds pretty darn comprehensive type inference support. I'm sorely tempted to use it everywhere possible to avoid undue repetition, but I'm wondering if removing explicit type information all over the place is such a good idea. Consider this rather contrived example:

Foo.h:

#include <set>

class Foo {
private:

    static std::set<Foo*> instances;

public:

    Foo();
    ~Foo();

    // What does it return? Who cares! Just forward it!
    static decltype(instances.begin()) begin() {
        return instances.begin();
    }

    static decltype(instances.end()) end() {
        return instances.end();
    }

};

Foo.cpp:

#include <Foo.h>
#include <Bar.h>

// The type need only be specified in one location!
// But I do have to open the header to find out what it actually is.
decltype(Foo::instances) Foo::instances;

Foo() {

    // What is the type of x?
    auto x = Bar::get_something();

    // What does do_something() return?
    auto y = x.do_something(*this);

    // Well, it's convertible to bool somehow...
    if (!y) throw "a constant, old school";

    instances.insert(this);

}

~Foo() {
    instances.erase(this);
}

Would you say this is reasonable, or is it completely ridiculous? After all, especially if you're used to developing in a dynamic language, you don't really need to care all that much about the types of things, and can trust that the compiler will catch any egregious abuses of the type system. But for those of you that rely on editor support for method signatures, you're out of luck, so using this style in a library interface is probably really bad practice.

I find that writing things with all possible types implicit actually makes my code a lot easier for me to follow, because it removes nearly all of the usual clutter of C++. Your mileage may, of course, vary, and that's what I'm interested in hearing about. What are the specific advantages and disadvantages to radical use of type inference?

Answer 1

Being mainly a Python programmer myself, I share the mindset that the programmer doesn't need to know the exact type. In the case of C++, especially when dealing with templated templated templated ... templates. Of course that's not because I despice static typing (I don't - I consider Haskell one of the best things since sliced bread, partially because of its static typing) but because I don't care about the exact type. Why, is not demonstrated well by examples that use names like foo or get_stuff(). So let's choose something closer to reality:

auto users = get_users();
vector<decltype(users[0])> blocked_users;
/* I'm not a C++ guru, much less C++0x so forgive me if type
   inference and foreach must be combined differently */
for (auto user : users) {
    if (check_name(user.name)) blocked_users.push_back(user)
}

Not a single type annotation, but it's perfectly clear what it does, right? This code doesn't care what's the type of users, it just need some range to iterate over which contains things with a name that can be fed to check_name. Nothing more. Nobody cares about the 100-ish characters of type names you'd have to type otherwise.

Same applies to most code with meaningful names. The example in the question is not clear, but it wouldn't be clear with explicit type names either, because neither context nor identifiers give any indication of what's going on. Use meaningful identifiers, and the code can be understood regardless of explicit type annotations.

Answer 2

The reason they brought in inference was to prevent people from writing code like:

foo().bar().baz().etc();

When you could write:

Foo f = foo();
Bar b = f.bar();
...

Except Foo would be some long templated type, so it becomes nicer to write:

auto f = foo();
auto b = f.bar();
...

So, as a rule of thumb, if using auto causes you to write code as above instead of code similar to the first example then by all means use it. Otherwise, stick to adding explicit definitions.

Answer 3

There are good reasons for not always using type inference. Haskell has type inference, but I usually declare function types explicitly anyway. That is partially a result of my development style. I declare the function first:

myFunction :: [Int] -> Int
myFunction xs = undefined

Next, I'll write the code that uses that function and do a compile to make sure it type checks. Once it type checks, I'll go ahead with the implementation.

The other reason for declaring function types is that the declarations can serve as additional documentation. That this documentation is verified on every compile is a bonus.