Is size_t guaranteed to be an alias type to one of integer types?

Text from [support.types]:

The contents are the same as the Standard C library header , with the following changes:

The type size_t is an implementation-defined unsigned integer type that is large enough to contain the size in bytes of any object.

From the C99 specification of stddef.h there is also this footnote for clarification:

224) Some of these types may denote implementation-defined extended integer types.

Since the C++ standard text does not specifically say that size_t must be a typedef, and since it appears to be based on C99, it seems to me that we should conclude that it may be an implementation-defined extended integer type.

Having said that, I don't know of any implementation for which it is not a typedef.

I'm not sure what you should do about your overload problem, however note that it is not limited just to size_t; there is also ptrdiff_t, and all of the fixed-width integer types. The latter are specified as being typedefs, however they are allowed to be aliases for extended integer types.

The C++ Standard says:

18.2/2 The contents are the same as the Standard C library header , with the following changes:

18.2/6 The type size_t is an implementation-defined unsigned integer type that is large enough to contain the size in bytes of any object.

18.2/7 [ Note: It is recommended that implementations choose types for ptrdiff_t and size_t whose integer conversion ranks (4.13) are no greater than that of signed long int unless a larger size is necessary to contain all the possible values. —end note ]

So, it doesn't say explicitly whether the implementation-defined unsigned integer type will be one of unsigned short, int, long, long long. The fact that 18.2/6 exists and specifies an "implementation-defined unsigned integer type" may be seen to override 18.2/2's default of following C, so any answer for C can't be trusted for C++.

The recommendation re conversion ranks implies the size_t will be expected to be one of the types mentioned in 4.13, where size_t isn't explicitly mentioned but the obvious candidates are, but that's no guarantee.

Do I need to provide a separate specialization for size_t?

You could use std::is_same and std::enable_if to do so when size_t is a distinct type....