`_t` type suffix is reserved by POSIX

[Y-Less]

Types ending with _t are reserved for use by the POSIX standard, to avoid future conflicts with existing code and newer revisions of the standards:

** B.2.12 Data Types **

The requirement that additional types defined in this section end in ‘‘_t’’ was prompted by the problem of name space pollution. It is difficult to define a type (where that type is not one defined by IEEE Std 1003.1-2001) in one header file and use it in another without adding symbols to the name space of the program. To allow implementors to provide their own types, all conforming applications are required to avoid symbols ending in ‘‘_t’’, which permits the implementor to provide additional types. Because a major use of types is in the definition of structure members, which can (and in many cases must) be added to the structures defined in IEEE Std 1003.1-2001, the need for additional types is compelling.

So basically, anyone using this library currently can't use it with any POSIX-compatible code, which seems an extremely likely scenario.

https://www.gnu.org/software/libc/manual/html_node/Reserved-Names.html

Names that end with ‘_t’ are reserved for additional type names.

[Morwenn]

POSIX targets C and not C++ though, so only if you want to follow this rule it only makes sense to avoid names ending in _t in the global namespace. If you don't want to use C++ libraries using names that end with _t in other namespaces then I fear that you can't use a huge part of the C++ ecosystem.

[johnmcfarlane]

... including much of the standard library such as the aliases for metafunctions in <type_traits>.

[nholthaus]

@johnmcfarlane and @Morwenn make good points.

That said, we're stripping out all _t naming conventions 3.0. Early on in the library development, what are now known as 'conversion factors' (basically tag types) seemed like they were going to be the first class types, and then when unit containers came into play we had to put the _t on to de-conflict.

It's been one of the least liked design decisions, and with 3.0 all unit containers will now be the plural of the unit name, e.g. meters vs. meter_t.

It's a massive API break though so we won't be making any naming changes to 2.x.