It's currently difficult to set a name for a thread: there's no cross-platform way in the standard library, and there's not even a common way to do it in UNIX-like systems, so the only solution currently is to write platform-specific code for each operating system using Win32 or non-portable pthread APIs.

Even so, every major operating system I'm aware of has a way to set a thread name, and setting thread names is often crucial for ease of debugging in multi-threaded systems. Having well-named threads also helps users of multi-threaded applications, as being able to see the purpose of a thread that's consuming a lot of CPU resources helps diagnose potential system configuration issues.

I believe that it deserves to be exposed as a convenient, standard API. I propose this set of functions:

* void std::this_thread::set_name(const char*): Set the name of the current thread
* const char *std::thread::get_name(): Member function to get the name of a thread
* const char *std::thread::get_name(std::thread::id): Static member function to get the name of a thread's name by ID

These functions would all need to have implementation defined behaviour, since there may be operating systems out there which don't have a concept of "the name of a thread". Different operating systems may also impose different implementation-defined limits, such as the maximum length of a name. Implementations could, for example, define 'std::this_thread::set_name' to be a no-op and define 'std::thread::get_name' to always return nullptr.

Design considerations:

1) Ideally, these functions would take std::string_view as an argument and return a std::string_view. However, since std::string_view is not null terminated, this would mean having to allocate a temporary null-terminated string in order to call the various OS-specific pthread functions to set a thread's name. Therefore, I believe it best to take a 'const char *' directly.

2) It's tempting to add a 'std::thread::set_name(const char *)' member function to set a thread's name by its handle. However, some operating systems (notably, macOS) do not have pthread functions to set the name of a different thread. I believe that in the vast majority of cases, software can be architected such that threads are responsible for setting their own names, and I do not foresee this causing issues.

Regards,
Martin Dørum