Date: Tue, 20 Aug 2019 15:00:29 +0300
Ville was right earlier in the thread; the scope of P1759R1 is very limited.
> 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 ...
> 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.
On 8/20/19 1:29 PM, Niall Douglas via Liaison wrote:
> On 19/08/2019 19:04, Billy O'Neal (VC LIBS) via Liaison wrote:
>> LEWGi looked at this in Cologne and said that they don’t want it, so I’m
>> not sure it’s appropriate to bug WG14 at this time:
>> http://wiki.edg.com/bin/view/Wg21cologne2019/P1759
>
> That vote appears to have assumed an ABI breaking replacement of
> std::thread::native_handle_type etc.
>
The results of that poll were affected by multiple factors:
* there was no paper arguing for it, and due to that, the exact
motivation and semantics were unclear
* I couldn't make Niall's case as well as he might've been able to
* implementation concerns due to a possible ABI break associated with
adding new members to an union
Should there be a paper arguing for this, with a solution for that third
bullet, I wouldn't see the vote going as negatively as it did back in July.
> 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 ...
> 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.
On 8/20/19 1:29 PM, Niall Douglas via Liaison wrote:
> On 19/08/2019 19:04, Billy O'Neal (VC LIBS) via Liaison wrote:
>> LEWGi looked at this in Cologne and said that they don’t want it, so I’m
>> not sure it’s appropriate to bug WG14 at this time:
>> http://wiki.edg.com/bin/view/Wg21cologne2019/P1759
>
> That vote appears to have assumed an ABI breaking replacement of
> std::thread::native_handle_type etc.
>
The results of that poll were affected by multiple factors:
* there was no paper arguing for it, and due to that, the exact
motivation and semantics were unclear
* I couldn't make Niall's case as well as he might've been able to
* implementation concerns due to a possible ABI break associated with
adding new members to an union
Should there be a paper arguing for this, with a solution for that third
bullet, I wouldn't see the vote going as negatively as it did back in July.
-- Elias
Received on 2019-08-20 07:02:33