> As it currently stands, native_handle_type has no mandatory semantics. That means that the implementation does whatever is necessary to make it work, for some unspecified meaning of "work".
>
> There's nothing in the standard that prevents an implementation from using a union, but that doesn't address the Windows issue. Under Windows you need (needed?) two different things, depending on what function you're calling. That's not a union; it's a struct with two elements.
>
> I don't see where requiring a discriminated union is better than allowing implementations to do what they need.

The problem I wish to solve is that C++ library implementations may
choose one of many internal implementations at runtime. For example, for
resumable i/o, one might choose IOCP or alertable i/o. For a condition
variable, one might choose lightweight condvars, or a Win32 semaphore.
And so on.

If one wishes to make available native handles, and we as a committee
seem to feel that we should, then is it not unreasonable that we
standardise some runtime mechanism of querying said native handles for
what kind of native handle they are?

One can of course build extensions to standard C++ library facilities
using implementation-specific APIs. I'm saying that we ought to expose
more implementation-specific information via the standard than we
currently do.

>> 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.
>
> Changed to what? That's why I asked: I don't know what the goal here is. If the intention is to provide portable semantics for native_handle_type, I think that's a mistake. We already have std::thread, std::mutex, etc. for portable code. The non-portable stuff, which is entirely implementation-defined, is done with native_handle_type.

Let's flip the proposed design around.

One could allow each C++ type to define its own native_handle_type.
Something bespoke to it.

One could then define a global polymorphic_native_handle_type which is a
union of all possible C++ standard library native handle types, plus an
API to query various things about the handle currently in union storage.

I don't personally have any skin in the game for threading objects. My
main concern is that P1031 Low level file i/o must drop its polymorphic
inheritance as per WG21 feedback, so I need an alternative way of
transferring native handles between management objects in a safe
fashion. One can create a handle, detach it from its management object,
attach it to a different management object in order to pass it through
more generic code.

Thus one needs to transmit, with the native handle instance, some
information about that native handle instance so implementation does the
right thing. For example, performing a blocking i/o upon a non-blocking
handle must emulate the blocking.

This is all fine for i/o type native handles, and perhaps what is
feasible here is a native_io_handle_type rather than native_handle_type.
Thoughts?

Niall