On Aug 19, 2019, at 11:10 AM, Niall Douglas via Liaison <liaison_at_[hidden]> wrote:
>
> 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?

That’s a major design change. Again: currently, native_handle_type has **no portable semantics**. The only thing you can do with a native_handle_type is pass it to an implementation-specific (i.e. non-portable) function. There are no standard library functions that take a native_handle_type.

If the standard adds support for determining the type (for whatever meaning of “type” is involved here), what then? What can you do **portably** that you can’t do without that information?

I was against native_handle_type when it was first proposed, precisely because it had no portable semantics. It seems to me that requiring it to be a discriminated union just makes this worse. It would still have no useful portable semantics (as intended), but it would have added complexity.

  — Pete Becker