This is no gotcha; he deliberately shoots himself in the foot by using a "weird" integer type. The right solution is to use value_type from container/iterator_traits (that is what it is there for):

    accumulate(begin(v), end(v), value_type{0});

Suggesting 0LL is just calling for trouble when someone realizes the vector didn't had to be long long and forgets to change the initialized value.

IMO one of the huge screw ups of the design of the STL is making sizes unsigned. It means that you get a compiler error when writing:

    for(auto i = 0; i < vec.size(); ...) {...}

since i and size() have different types. The worst part is that unsigned doesn't buy you that much (only twice as many elements).

The lesson to be learned here is: don't use weird integer types unless you really need to, and then, you should know what you are doing. E.g. if I need a long index then I use

    using Idx = long long;
    accumulate(begin, end, Idx{0});

when I'm hacking, and

    struct unique_tag {};
    using Idx = arithmetic_type<long long, unique_tag>;

when I'm serious to disable all implicit conversions and make these types of errors impossible.