On 19/08/2019 14:54, pete_at_[hidden] wrote:
> Can you be more specific about what is being proposed?

LEWG-I has forwarded P1759R1 to LEWG to begin standardisation. It
hard-assumes a one-one relation between "native_handle_type" and some
single implementation handle type.

I strenuously disagree with that design choice. One might be able to get
away with it on POSIX most of the time, but the world is not POSIX.

In the real world, there are many kinds of native handle type. That's
why it needs union storage in my opinion, and a discriminant to tell you
which is in play right now.

That's my proposal.

> In C++11, native_handle_type reserved a name with no portable semantics. The requirement is that it can be passed to various implementation-defined functions to do various implementation-defined things. I pointed out at the time that there was no single Windows type that supported all of the operations of std::thread on all the variants of Windows (in particular, WinCE had some quirks), so there was no obvious candidate for native_handle_type on Windows. The Dinkumware implementation (which I wrote) puts all the threading stuff on top of a portable layer (now more-or-less standardized in C), and native_handle_type is the corresponding type from that layer, i.e., not a native Windows type.

You make an excellent point that one of the union options ought to be
pthread_t.

Be aware that nobody is proposing that std::thread::native_handle_type
be immediately changed. This would break ABI. However it may become
changed if a toolchain breaks ABI.

Niall