Are you sure that there is an improvement as it's just some enum ?
it's an improvement when it's a class but for an enum not sure .

It's the size of the container itself (and its heap allocations) that we reduce. The old code constructs an empty array list, and then calls operator<< n times. For every such call, QList allocates a new array on the heap, one element larger in size than the last one, and then moves the old contents to the new location. That's what I figured out by looking at QList's source code (QList::operator(t)<< calls QList::append(t) calls QListData::append() calls QListData::append(1), which does exactly what I just described) , but maybe I missed some mechanism that batch allocates more space than needed, just as QVector does. But even if it did, QList cannot know at the beginning of the << sequence how much space it would need eventually. So even with vectors' trick to allocate some constant fraction of the previously used amount of memory when size hits capacity, we would have log(n) memory allocations for n insertions. Using the ctor directly reduces this to only one heap allocation.

Using the initializer list ctor of QList might be just as efficient in this case. Frankly, I'm not an expert on Qt containers. I just watched Milians CppCon15 talk on Qt yesterday, where he said that QList should probably die in favor of QVector, and only be used where it has to be passed to some function that only excepts QList, so I switched.

Technically, since the list here is only created so that it can be effectively iterated over, you could just do

const auto myActions = { .....  };

The deduced type will be std::initializer_list<T>, which is just a light wrapper for an array which can be iterated over in range-based loops. This is probably even more light-weight and faster than using QVector.

Also for QList<T> where sizeof(T) <= sizeof(void*), QList uses an optimization and stores the values directly in the contigous pointer array, thus behaving the same way as QVector more or less.

Yes, I saw the optimization for types that are not ::isLarge, but we still require the array. And your auto version removes the last three heap allocations, which is great. I'll update my diff accordingly.