Good luck implementing something like std::is_standard_layout without "magic language hacks". No, not all libraries are made equal and std is part of the language now, there is no way back

You've cherry-picked a type trait as your example, which arguably could be a core language feature made to look like a third-party module.

Meanwhile, do you believe it's hard to implement a container?

And no, adding cruft to the STL is not a one-way street. See for example the history of C++'s smart pointers.

It is pretty hard to implement a container with all the precise invariants and guarantees that the Standard requires.

But more to the point, your implementation might still not be as fast as the standard library one, because the standard library can make assumptions about the compiler that you cannot in portable code - what is UB to you might be well-defined behavior to stdlib authors. Thus, for example, they might be able to use memcpy for containers of stdlib types that they know are safe to handle in that manner.

A look into the type_traits header reveals that is_standard_layout is implemented with standard C++.

This is absolutely false.

https://github.com/llvm-mirror/libcxx/blob/master/include/ty...

It checks if a non standard feature is available, otherwise falls back to a standard implementation.

My argument was that it was possible to implement it with standard C++.

There's no way to implement that type trait using standard C++. The implementation does check if a non-standard feature is available, and if not it delegates to is_scalar which in turn delegates to is_enum which in turn delegates to is_union. is_union can not be implemented in a standard conforming manner without compiler support and libc++ unconditionally returns false if compiler support is not available, which does not conform to the standard.