On Mon, 19 Aug 2019 at 17:38, pete--- via Liaison
<liaison_at_[hidden]> wrote:
> > You make an excellent point that one of the union options ought to be
> > pthread_t.
>
> That's not my point at all.
>
> 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.
>
> >
> > 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.

I don't quite follow what this message thread is about. All the
proposal is proposing is the addition of a nested native_handle_type
and getters for such into iostreams types. There's no universal handle
type being proposed, and whether it's a union seems completely
irrelevant. It's not a portable-semantics native handle type either.
All it does is that it allows me to get a native handle from, say,
fstream,
and pass that handle along to, say fcntl. Why it should deal with any
unions or pthread_t is completely beyond me.