220 15570 <7c4dadde-1f85-4a25-a05d-535cbd2f8278@isocpp.org> article Path: news.gmane.org!not-for-mail From: gmisocpp@gmail.com Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: RFC: Adding Symmetry Between shared_ptr and weak_ptr Date: Sat, 10 Jan 2015 13:26:19 -0800 (PST) Lines: 146 Approved: news@gmane.org Message-ID: <7c4dadde-1f85-4a25-a05d-535cbd2f8278@isocpp.org> References: Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_394_719413188.1420925179890" X-Trace: ger.gmane.org 1420925187 18151 80.91.229.3 (10 Jan 2015 21:26:27 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 10 Jan 2015 21:26:27 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBCM3TRNUXUDBB7NRY2SQKGQEIYSAFHI@isocpp.org Sat Jan 10 22:26:23 2015 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-pa0-f69.google.com ([209.85.220.69]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1YA3Y7-0002pN-H5 for gclcip-std-proposals@m.gmane.org; Sat, 10 Jan 2015 22:26:23 +0100 Original-Received: by mail-pa0-f69.google.com with SMTP id et14sf145828041pad.0 for ; Sat, 10 Jan 2015 13:26:22 -0800 (PST) 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 :content-type:x-original-sender:reply-to:precedence:mailing-list :list-id:list-post:list-help:list-archive:list-subscribe :list-unsubscribe; bh=MPEW1y3HDWzzebRISSFvfXQf3HWqYpviKRtXY7FaJGI=; b=CAN3ePaOzGU+suhyzpoT6KT42p11aC73Y3MCZBggOxVlHXV0uZSLWG5pdFrXeG8aXi KeOYq5gYgwIIzxKTl5H7ucynf6fCyB7NO5AzsrMj3QCty7PaNii8W8G7cQONWhE2i2ax N48tUJQVOwy3siFWtLGMkwxbk4o+WfeTtfWSBTgwT/Ay1UEb+zgxgoLfAZkoAm0GlBzK F5EpmoPTi/VEn9Z5qBsUqyrSF4zNKBKW7Majvw3hPaZNENgTk0J+w2roBoGoJNUcqgo7 aqxZAJ0Pv7tdX2EpdWb2eIKorq8a2k53w6z9JgFr3KQqMEH5bngeOsH33jPlgkKMEt08 RsqA== 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:content-type:x-original-sender:reply-to :precedence:mailing-list:list-id:list-post:list-help:list-archive :list-subscribe:list-unsubscribe; bh=MPEW1y3HDWzzebRISSFvfXQf3HWqYpviKRtXY7FaJGI=; b=aFkDyslySms6TlLPHQLeoHluuq6kevnOe07bEb85vES9767r6yD08otREfHvMgffK7 OnjOksEhO8vEQMuFdy7HLTbSaSZDPMddfWRyfhJjdWCfAhFuJBgX6RmZDRJjUfUpI2V7 k5SoP3ascGSiWZKQtaT1gUh1JDZlxWpHkbj5RW1tvusIs3Jc3g8kwEzxM405Y2Hn1hLA pxenRZXOStGphMp+JJwkopUvxwjo/zwB51+86ckmaWT1kL9iWv7yjmFORX+hJDKNWPrF wmnJ+jPAqi2ET0jh7LNV10V/qYsMNJzpQyktRprOkc3i883QYYlV+1hKXXjA6hIWuV0s IqPw== X-Gm-Message-State: ALoCoQmJbaLydkim6Kjc8EJzAyUv5CxVjyag6tjb5AAQK2XmCk5abMRgPS2QhsuN5Qkv7V8fuPeX X-Received: by 10.66.142.100 with SMTP id rv4mr17019249pab.21.1420925182289; Sat, 10 Jan 2015 13:26:22 -0800 (PST) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.107.25.194 with SMTP id 185ls1390162ioz.5.gmail; Sat, 10 Jan 2015 13:26:20 -0800 (PST) X-Received: by 10.50.253.1 with SMTP id zw1mr135689igc.11.1420925180928; Sat, 10 Jan 2015 13:26:20 -0800 (PST) In-Reply-To: X-Original-Sender: gmisocpp@gmail.com Precedence: list Mailing-list: list std-proposals@isocpp.org; contact std-proposals+owners@isocpp.org List-ID: 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:15570 Archived-At: ------=_Part_394_719413188.1420925179890 Content-Type: multipart/alternative; boundary="----=_Part_395_844518106.1420925179890" ------=_Part_395_844518106.1420925179890 Content-Type: text/plain; charset=UTF-8 Nice proposal. On Sunday, January 11, 2015 at 8:10:59 AM UTC+13, Ville Voutilainen wrote: > > On 10 January 2015 at 21:01, Arthur O'Dwyer > wrote: > > I've got a rough draft of a proposal for the next meeting in May, and > would > > like to hear anyone's feedback on the format and content before then. > > > > https://quuxplusone.github.io/draft/Nweak_ptr_proposal.html > > > > The TL;DR is that it proposes two very small new library features: > > - shared_ptr::unlock(), which turns a shared_ptr into a weak_ptr, > symmetric > > with weak_ptr::lock() > > - An two-argument constructor for weak_ptr(), symmetric with > shared_ptr's > > two-argument constructor > > > Looks good to me, I found the rationale (and the whole proposal) very > reasonable and well-written. > Ville, a few things slightly touched on by this proposal: In your view, if the naming of lock/unlock is of sufficient irritation, would it be so bad to add [[deprecated]] to the existing names and/or add the preferred new ones? And if there are sufficient other candidates where renaming might be useful, like the empty() -> is_empty() example referenced; would collecting the simpler cases up and having a consolidated proposal to fix them all help procedure wise in general versus lots of individual cases? If so, we could make a separate post asking for rename recommendations. I saw renaming shared_mutex -> timed_shared_mutex or something was another rename case floating around at one point, but I'm sure that one or some might be better handled as separate proposals. And is there any reason not to make [[warn_unused_result]].standard now? Isn't it time we did that so this proposal and everyone can benefit from it? I think I suggested this before but I think it got shot down. But I might be wrong Right now I can't see why this attribute shouldn't be standard. It seems like even things like strlen() would benefit from it. I mean why calculate a strings length if you don't capture or use the result anywhere. Something tells me someone will have a good reason, even for this particular example lol. -- --- 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. Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/. ------=_Part_395_844518106.1420925179890 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Nice proposal.

On Sunday, January 11, 2015 at 8:10:= 59 AM UTC+13, Ville Voutilainen wrote:
On 10 Ja= nuary 2015 at 21:01, Arthur O'Dwyer <arthur....@gmail.com> wrote:
> I've got a rough draft of a proposal for the next meeting in May, = and would
> like to hear anyone's feedback on the format and content before th= en.
>
> https://quuxpl= usone.github.io/draft/Nweak_ptr_proposal.html
>
> The TL;DR is that it proposes two very small new library features:
> - shared_ptr::unlock(), which turns a shared_ptr into a weak_ptr, = symmetric
> with weak_ptr::lock()
> - An two-argument constructor for weak_ptr(), symmetric with share= d_ptr's
> two-argument constructor


Looks good to me, I found the rationale (and the whole proposal) very
reasonable and well-written.

Ville, a few things slightly touc= hed on by this proposal:

In your view, i= f the naming of lock/unlock is of sufficient irritation= , would it be so bad to add [[deprecated]] to the exist= ing names and/or add the preferred new ones?

=
And if there are sufficient other candidates where renaming = might be useful, like the empty() -> is_empty() example refere= nced; would collecting the simpler cases up and having = a consolidated proposal to fix them all help procedure wise in general vers= us lots of individual cases? If so, we could make a separate post aski= ng for rename recommendations. I saw renaming shared_mutex -> timed= _shared_mutex or something was another rename case floating aroun= d at one point, but I'm sure that one or some might be better han= dled as separate proposals.
=
And is there any re= ason not to make [[warn_unused_result]]<= /code>.standard now? Isn't it time we did that so this proposal and ev= eryone can benefit from it?
I think I suggested this before but I= think it got shot down. But I might be wrong Right now I can't see wh= y this attribute shouldn't be standard.
It seems like even things= like strlen() would benefit from it. I mean why calculate a strings length= if you don't capture or use the result anywhere. Something tells me someon= e will have a good reason, even for this particular example lol.<= /div> 

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/<= /a>.
------=_Part_395_844518106.1420925179890-- ------=_Part_394_719413188.1420925179890-- .