On 19/08/2019 16:51, Versatilecoding 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**.

Only because we have chosen that to be the case.

There is precedent here. You can ask POSIX what kind of inode a file
descriptor refers to. Same goes here for native handle type, which
similarly refers to some implementation-defined-structure-elsewhere.
Indeed, as you may have noticed in my forwarded message to WG14, one
could even use mode_t as the union discriminant on POSIX platforms.

> 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.

I agree that i/o capable native handle types is a much easier ask to
achieve consensus. For those, one can write generic code that can work
with any kind of i/o capable native handle type. For example, you can
supply a socket, a fifo, a file, a block device, or even a symlink, and
a function implementation can "just work".

Ok, thanks for the useful feedback.

Niall