220 25697 <32e023f0-a4f6-4914-a7ae-6a3b330e1229@isocpp.org> article Path: news.gmane.org!not-for-mail From: Arthur O'Dwyer Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Why joining_thread and no detaching_thread? Why not a policy-based thread? Date: Thu, 28 Apr 2016 19:26:39 -0700 (PDT) Lines: 192 Approved: news@gmane.org Message-ID: <32e023f0-a4f6-4914-a7ae-6a3b330e1229@isocpp.org> References: <61f3b26a-360d-45d9-b949-b9d0d63d96ab@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_23_937232287.1461896799203" X-Trace: ger.gmane.org 1461896812 19538 80.91.229.3 (29 Apr 2016 02:26:52 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 29 Apr 2016 02:26:52 +0000 (UTC) To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBDLZJYWNDQIOFDELXECRUBGRRBMIO@isocpp.org Fri Apr 29 04:26:45 2016 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-pa0-f71.google.com ([209.85.220.71]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1avy8j-0007Gw-0N for gclcip-std-proposals@m.gmane.org; Fri, 29 Apr 2016 04:26:45 +0200 Original-Received: by mail-pa0-f71.google.com with SMTP id dx6sf148797546pad.0 for ; Thu, 28 Apr 2016 19:26:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isocpp-org.20150623.gappssmtp.com; s=20150623; h=date:from:to:message-id:in-reply-to:references:subject:mime-version :x-original-sender:reply-to:precedence:mailing-list:list-id :x-spam-checked-in-group:list-post:list-help:list-archive :list-subscribe:list-unsubscribe; bh=SWTMopU5/mCPjzK+JLHXIdqFhA2E79qdd6Repcq4JVk=; b=mc1uwUSexWuwgfN2GOjejCAHjAlUbp0ySFeJ8AHEqkAYJOP/X7EOR+GnlLVekfzBKD X4k8Wu3GarXH1GHdphE6myZS3qiZX8WcN8UPvjZLdCc5XjMcd4zWqwvr4QiTSei/i29D 5wi+QHgzJqzBRLuG/lD3OKEObElYcgN+ZJSo3XTdBuKbEaZzq5ccA6nfgAyjLgkxfDi3 nWAvhDvDI4zYNVoPvTdeNq4yiZ08Aj9lIUEjJlJ8chYuPEBJ8OM+t20QUpNPixIeVkGe 90jrtTeXACoQq9Npo177Bos91u6af6/uxwNsI3kcDTn1Jg3O0LnxM8YqybTodwGDfZJQ ov0w== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:message-id:in-reply-to:references:subject:mime-version :x-original-sender:reply-to:precedence:mailing-list:list-id :x-spam-checked-in-group:list-post:list-help:list-archive :list-subscribe:list-unsubscribe; bh=SWTMopU5/mCPjzK+JLHXIdqFhA2E79qdd6Repcq4JVk=; b=dNuv86+v/FpHZtDpRJqFLSk4lnbxK1ANCOLxJMyXkCqb36/1s+E7hcbRNFl+FAmns+ ay1TaV2v6KRsdpQybYFnWZQNwfgvVIpGgXUyTlj2x4PGZLW7ieo4orUXAVi4fQ8ARqwu EQv2HDEz5cWTUtDJ602bNXW5exdljNVMPOJNocS2jOpXd2rX3RUZR8LnGJVOtS6geR8C gmtXnBDKxqcDM5EKX+pQgKfLIdeL6duhkXYGD6atVDul1VMvOJHWoKfSmCX0br7rBW9B DssnLSImpx5YIf0vKEHx1twLJIFzFA1qCOsBnCN+IsSDf3PBv9Zm05PI32CL7n9lvSCG 2EsQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:to:message-id:in-reply-to:references :subject:mime-version:x-original-sender:reply-to:precedence :mailing-list:list-id:x-spam-checked-in-group:list-post:list-help :list-archive:list-subscribe:list-unsubscribe; bh=SWTMopU5/mCPjzK+JLHXIdqFhA2E79qdd6Repcq4JVk=; b=i3fOXAUeNn1Q+SsLQOW8XPzG2BKBLp26YmXU2+Vo0ElPcQMbQ+eD40A3mVPv3I3Mfa 6y8+5FBhqyMmb7plfpL4/pjO4K0IT5vgmciXysNt6cJuzHofC4o61igqe6na2aeXq/6E THJIfg5icVuPXvjMTQiRCmHc9LDCXVfCEKanrqkvrAV4LclHuoDCJNdQeUbfeZL5B8i8 B6n0IO20DAy4IQIuq61Zmxlyp3qozqV0U7K0/3YMlxb1MStBNjSi8gaciiPuUn+pRFbd 563lk75k7UT8AV/zL19euWLx37x4jtYID4dBDfE1bFd26eFIwvUhOjOmIe+CPBTctp9/ 6HQw== X-Gm-Message-State: AOPr4FXNNEuc6XWolWzsQsDPSYEeFNj9lmJVVZCvklNjpSXswnmKwXKY3sx8qD/ab53iFg== X-Received: by 10.66.90.74 with SMTP id bu10mr8277237pab.31.1461896803828; Thu, 28 Apr 2016 19:26:43 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.107.192.193 with SMTP id q184ls794770iof.56.gmail; Thu, 28 Apr 2016 19:26:42 -0700 (PDT) X-Received: by 10.50.219.162 with SMTP id pp2mr2583igc.1.1461896802612; Thu, 28 Apr 2016 19:26:42 -0700 (PDT) In-Reply-To: X-Original-Sender: arthur.j.odwyer@gmail.com Precedence: list Mailing-list: list std-proposals@isocpp.org; contact std-proposals+owners@isocpp.org List-ID: X-Spam-Checked-In-Group: std-proposals@isocpp.org X-Google-Group-Id: 399137483710 List-Post: , List-Help: , List-Archive: List-Subscribe: , List-Unsubscribe: , Xref: news.gmane.org gmane.comp.lang.c++.isocpp.proposals:25697 Archived-At: ------=_Part_23_937232287.1461896799203 Content-Type: multipart/alternative; boundary="----=_Part_24_76740170.1461896799203" ------=_Part_24_76740170.1461896799203 Content-Type: text/plain; charset=UTF-8 http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0206r0.html http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0206r1.html Ville, I've only just read the paper and have no background on what the Committee discussion has already been, except as recorded in http://wiki.edg.com/bin/view/Wg21jacksonville/P0206 .. p0206r1 looks like a slam-dunk to me, except for one little piece that confuses me: p0206r0 proposed a "convert joining-thread to plain-old-thread" member function with signature thread to_thread(); and semantics "*this is set to a default constructed state. The state of the returned object is the state *this had prior to calling this function. Returns: A thread object initialized from *this." In p0206r1, this has changed to thread& as_thread(); const thread& as_thread() const; with the note: "The functions are intentionally not ref-qualified, they intentionally return a reference rather than a value, and it's intentional that there are no overloads that return rvalue references." I understand why ref-qualified functions and functions returning rvalue references are undesirable (as a general rule). I don't understand why functions returning *values* are undesirable, though, and p0206r1 doesn't offer any further explanation. Elsewhere in the standard library, we have similar cases of "I have a (potentially non-copyable) A; I need to produce a corresponding B". My intuition is that they're usually of the value-returning form: - auto std::future::share() -> std::shared_future - auto std::weak_ptr::lock() const -> std::shared_ptr (okay, weak_ptr is copyable, so this member function gets to be const) and there are also some of the "constructor-taking-rvalue-reference" form: - std::shared_ptr::shared_ptr(std::unique_ptr&&) Either way, IMO there's a strong intuition that returning pointers (or references) into your own parameters' innards is a *bad thing*. IMO, either (A) std::thread as_thread(); // with semantics as in p0206r0 [...] auto jt = make_joining_thread(); auto t = jt.as_thread(); assert(!jt.joinable()); auto t2 = make_joining_thread().as_thread(); or (B) std::thread::thread(std::joining_thread&&); [...] auto jt = make_joining_thread(); auto t = std::thread(std::move(jt)); assert(!jt.joinable()); auto t2 = std::thread(make_joining_thread()); would be very much preferable to p0206r1's reference-returning versions (C) std::thread& as_thread(); const std::thread& as_thread() const; [...] auto jt = make_joining_thread(); auto t = std::move(jt.as_thread()); assert(!jt.joinable()); auto t2 = std::move(make_joining_thread().as_thread()); I happen to prefer (A) because the named member function is more explicit, but even (B) seems better to me than p0206r1's two dangling-reference-returning signatures. IMHO, novices (the target audience, right?) will not enjoy having to deal with std::move and dangling references out of the box. I think they'll prefer a version that uses value semantics and doesn't require std::move, even if it does involve giving side-effects to a member function. But was the Committee discussion really in favor of the reference-returning signatures? and if so, why? my $.02, Arthur -- You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group. To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org. To post to this group, send email to std-proposals@isocpp.org. To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/32e023f0-a4f6-4914-a7ae-6a3b330e1229%40isocpp.org. ------=_Part_24_76740170.1461896799203 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/20= 16/p0206r0.html
http://www.open-std.org/jtc1/sc22/wg21/docs/p= apers/2016/p0206r1.html

Ville,

<= /div>
I've only just read the paper and have no background on what = the Committee discussion has already been, except as recorded in
= http://wiki.edg.com/bin/view/Wg21jacksonville/P0206
. p0206r1 loo= ks like a slam-dunk to me, except for one little piece that confuses me:

p0206r0 proposed a "convert joining-thread to p= lain-old-thread" member function with signature

=C2=A0 =C2=A0 thread to_thread();

and semantics &quo= t;*this is set to a default constructed state. The state=C2=A0of the return= ed object is the state *this had prior to calling this function. Returns: A thread object initialized from *this."

= In p0206r1, this has changed to

=C2=A0 =C2=A0 thread& as_threa= d();
=C2=A0 =C2=A0 const thread& as_thread() const;

w= ith the note: "The functions are intentionally not ref-qualified, they= intentionally return a reference rather than a value, and it's intenti= onal that there are no overloads that return rvalue references."
=
I understand why ref-qualified functions and functions returning rvalu= e references are undesirable (as a general rule). I don't understand wh= y functions returning values are undesirable, though, and p0206r1 do= esn't offer any further explanation.

Elsewhere i= n the standard library, we have similar cases of "I have a (potentiall= y non-copyable) A; I need to produce a corresponding B". My intuition = is that they're usually of the value-returning form:
- auto s= td::future<T>::share() -> std::shared_future<T>
- auto std::weak_ptr<T>::lock() const -> std::shared_ptr<T>= ; =C2=A0(okay, weak_ptr is copyable, so this member function gets to be con= st)

and there are also some of the "construct= or-taking-rvalue-reference" form:
- std::shared_ptr<Y,D&g= t;::shared_ptr(std::unique_ptr<Y,D>&&)

Either way, IMO there's a strong intuition that returning pointers (= or references) into your own parameters' innards is a bad thing.=

IMO, either (A)

=C2=A0 = =C2=A0 std::thread as_thread(); =C2=A0// with semantics as in p0206r0
=

=C2=A0 =C2=A0 [...]
=C2=A0 =C2=A0 auto jt =3D= make_joining_thread();
=C2=A0 =C2=A0 auto t =3D jt.as_thread();<= /div>
=C2=A0 =C2=A0 assert(!jt.joinable());
=C2=A0 = =C2=A0 auto t2 =3D make_joining_thread().as_thread();

<= /div>
or (B)

=C2=A0 =C2=A0 std::thread::thread= (std::joining_thread&&);

=C2=A0 =C2= =A0 [...]
=C2=A0 =C2=A0 auto jt =3D make_joining_thread();
<= div>=C2=A0 =C2=A0 auto t =3D std::thread(std::move(jt));
=C2=A0 = =C2=A0 assert(!jt.joinable());
=C2=A0 =C2=A0 auto = t2 =3D std::thread(make_joining_thread());

w= ould be very much preferable to p0206r1's reference-returning versions = (C)

=C2=A0 =C2=A0 std::thread& as_thread();=C2=A0 =C2=A0 const std::thread& as_thread() const;
<= br>
=C2=A0 =C2=A0 [...]
=C2=A0 =C2=A0 auto jt= =3D make_joining_thread();
=C2=A0 =C2=A0 auto t =3D std::move(jt= ..as_thread());
=C2=A0 =C2=A0 assert(!jt.joinable());
=C2=A0 =C2=A0 auto t2 =3D std::move(make_joining_thread().as_thread= ());

I happen to prefer (A) because the name= d member function is more explicit, but even (B) seems better to me than p0= 206r1's two dangling-reference-returning signatures.

IMHO, novices (the target audience, right?) will not enjoy having to= deal with std::move and dangling references out of the box. I think they&#= 39;ll prefer a version that uses value semantics and doesn't require st= d::move, even if it does involve giving side-effects to a member function.<= /div>

But was the Committee discussion really in f= avor of the reference-returning signatures? and if so, why?

<= /div>
my $.02,
Arthur

--
You received this message because you are subscribed to the Google Groups &= quot;ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e= mail to std-proposa= ls+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.= com/a/isocpp.org/d/msgid/std-proposals/32e023f0-a4f6-4914-a7ae-6a3b330e1229= %40isocpp.org.
------=_Part_24_76740170.1461896799203-- ------=_Part_23_937232287.1461896799203-- .