220 15585 <5b22e30d-2f59-4aa9-8d29-78ba6b68aba5@isocpp.org> article Path: news.gmane.org!not-for-mail From: Arthur O'Dwyer Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: RFC: Adding Symmetry Between shared_ptr and weak_ptr Date: Sun, 11 Jan 2015 12:33:39 -0800 (PST) Lines: 210 Approved: news@gmane.org Message-ID: <5b22e30d-2f59-4aa9-8d29-78ba6b68aba5@isocpp.org> References: <7c4dadde-1f85-4a25-a05d-535cbd2f8278@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_2443_972956686.1421008419367" X-Trace: ger.gmane.org 1421008429 28006 80.91.229.3 (11 Jan 2015 20:33:49 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 11 Jan 2015 20:33:49 +0000 (UTC) Cc: gmisocpp@gmail.com To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBDLZJYWNDQIKHPGLUUCRUBBJIZQDG@isocpp.org Sun Jan 11 21:33:44 2015 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 1YAPCf-0000QF-NX for gclcip-std-proposals@m.gmane.org; Sun, 11 Jan 2015 21:33:42 +0100 Original-Received: by mail-pa0-f71.google.com with SMTP id rd3sf176712744pab.2 for ; Sun, 11 Jan 2015 12:33:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc: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=/muEv0ceyCFAcfrv/Z9IbHoTvtPX+VEW3q/YAf8a8TY=; b=i9Gr2iKxZvopyLI5ipZytaWikYkgtLED66JbBQD/j7AvD1D6LIY21z1A0AI9FZQhua eBUJfgWaWqCt8VxXD+Xys4EGCJuyE6MhNgy4nw1Z5Hf2bm924pmiOd8tSKLnJQdQjMSy Vrxqj+gnouRjg13BG3nlpUPFrsSsvs01Zh67HDINhcu1xNB+Ku41wL8aDRFmx6Tb3MKl fmRhCCj3QYSGd2YjfPqnDmGyRIPyAkU2zF19ShCs7jckSCBfP5vw2CVZ0Pl2inx7YP+W phR6OO7zL4EmCw6vqLTIW+p8tX3nSyGA6/7c2tldaHsFTt0+2/cLCkQ0oYvtSj6AE9Kg 0fUg== 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:cc: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=/muEv0ceyCFAcfrv/Z9IbHoTvtPX+VEW3q/YAf8a8TY=; b=aGfj9aP9++qw3SHUY6nYrj8sj8L4p3j0TnC4ABQotzebueEKepk9gfMy4gnVVlIGNK oXMoK6Tew96701EQrOXiFEM6JudHGugAq69QyUVeTP34zPMzJEEL/lL6tLmiCLyu7iBl zP67q0aC+7Mbo+6h++F0FQ98KR72VjAPQ9TtD2IP355xNOHqVOV5etfxFF6KPkcYZIxt ehKgXYwQ+sU710lhYaf8NLg31DaywP8TCaOK5ZWM73RcFMHCxWOi+2+KQMdiehFaC3A6 bFWHmICIM/PetnUkxIEC4WsKEHHlD9bYBqUU+jasvS4uRapd2+HRdZRX46PBgs1wIk71 WFkw== X-Gm-Message-State: ALoCoQlsPeMc5/uoteHQIOKZkyn3crlno7AjFrAXIN4GZc7QDI2uJfa5Uym3h9dkrxZS8DsPVSrh X-Received: by 10.67.23.33 with SMTP id hx1mr1940459pad.45.1421008420727; Sun, 11 Jan 2015 12:33:40 -0800 (PST) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.140.20.105 with SMTP id 96ls2411431qgi.20.gmail; Sun, 11 Jan 2015 12:33:39 -0800 (PST) X-Received: by 10.140.97.200 with SMTP id m66mr83qge.42.1421008419739; Sun, 11 Jan 2015 12:33:39 -0800 (PST) In-Reply-To: <7c4dadde-1f85-4a25-a05d-535cbd2f8278@isocpp.org> 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-Google-Group-Id: 399137483710 List-Post: , List-Help: , List-Archive: List-Subscribe: , List-Unsubscribe: , Xref: news.gmane.org gmane.comp.lang.c++.isocpp.proposals:15585 Archived-At: ------=_Part_2443_972956686.1421008419367 Content-Type: multipart/alternative; boundary="----=_Part_2444_1542533344.1421008419367" ------=_Part_2444_1542533344.1421008419367 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Saturday, January 10, 2015 at 1:26:20 PM UTC-8, gmis...@gmail.com wrote: > > Nice proposal. > Thanks! =20 > In your view, if the naming of lock/unlock is of=20 > sufficient irritation, would it be so bad to add [[deprecated]] to the=20 > existing names and/or add the preferred new ones? > > And if there are sufficient other candidates where renaming might be=20 > useful, like the empty() -> is_empty() example referenced; would collecti= ng=20 > the simpler cases up and having a consolidated proposal to fix them all= =20 > help procedure wise in general versus lots of individual cases? If so, we= =20 > could make a separate post asking for rename recommendations. I saw=20 > renaming shared_mutex -> timed_shared_mutex or something was another rena= me=20 > case floating around at one point, but I'm sure that one or some might be= =20 > better handled as separate proposals. > Deprecating std::vector::empty() is a non-starter. :D And far, far outside= =20 the scope of this proposal, of course. Deprecating or renaming std::shared_ptr::lock() is also a non-starter, in= =20 my opinion, even though it's a couple orders of magnitude more obscure than= =20 vector::empty(), and has only been around since C++11. Hence my "If it were= =20 not too late to rename..." comment in the paper. The shared_mutex -> shared_timed_mutex renaming seems to have gone as=20 follows: N2406 (2007-09-09) (Hinnant): shared_mutex is proposed for TR2. (The name= =20 comes from Boost.) It is still absent from C++11 working draft N3337. N3427 (2012-09-23), N3568 (2013-03-11), N3659 (2013-04-19) (Hinnant):=20 shared_mutex is introduced to the standard. N3659 is adopted into working= =20 draft N3797. N3891 (2014-01-14) (Sutter, Nishanov): shared_mutex is renamed to=20 shared_timed_mutex. Adopted at Issaquah into (current) working draft N4296. N3961 (2014-02-25), N3995 (2014-05-20) (Nishanov): A coauthor of N3891=20 proposes a new class shared_mutex that lacks timing functionality. Observe that the original attitude "let's put timeout functionality into=20 shared_mutex" came from Boost, and the new attitude "let's make timeout=20 support optional" came from Microsoft. This is apparently for technical=20 reasons on Windows: they have a fast reader-writer lock that lacks timeout= =20 support, and a heavyweight one that has timeout support, so they really=20 want a place in the standard library to expose the fast one. The new,=20 untimed std::shared_mutex will provide such a place. In other words, that particular renaming had solid technical reasons and=20 the weight of Microsoft behind it; it wasn't a purely stylistic change. I= =20 don't think any purely stylistic changes like empty()->is_empty() or=20 lock()->strengthen() will ever happen. There might be some precedent for the Standard's providing silly *synonyms*= =20 for the existing constructs, analogous to how they made 'and' a synonym for= =20 '&&', but again, that was a change made (in 1991) for ostensibly technical= =20 reasons, and had the weight of IBM behind it. ftp://std.dkuug.dk/mirror/www.maths.warwick.ac.uk/cpp/iso/minutes/91-0093.t= xt And is there any reason not to make [[warn_unused_result]].standard now?=20 > 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 migh= t=20 > 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= =20 > calculate a strings length if you don't capture or use the result anywher= e.=20 > Something tells me someone will have a good reason, even for this=20 > particular example lol. > I think I agree that [[warn_unused_result]] should be standardized, but=20 again that's obviously far, far out of scope for this proposal. That proposer should look at 7.6.5 [dcl.attr.deprecated] for the=20 appropriate wording. =E2=80=93Arthur --=20 ---=20 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 e= mail 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-proposa= ls/. ------=_Part_2444_1542533344.1421008419367 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Saturday, January 10, 2015 at 1:26:20 PM UTC-8, gmis...= @gmail.com wrote:
Nice proposal.

Thanks!
<= div> 
In your view, if the naming of lock/unlock is o= f sufficient irritation, would it be so bad to add= [[deprecated]] to the existing names and/or add the preferred ne= w ones?

And if there are sufficient = other candidates where renaming might be useful, like the em= pty() -> is_empty() example referenced; would collecting the s= impler cases up and having a consolidated proposal to fix them al= l help procedure wise in general versus lots of individual cases? If s= o, we could make a separate post asking for rename recommendations. I saw r= enaming shared_mutex -> timed_shared_mutex or something was an= other rename case floating around at one point, but I'm sure that= one or some might be better handled as separate proposals.
=

Deprecating std::vector::empty= () is a non-starter. :D  And far, far outside the scope of this propos= al, of course.
Deprecating or renaming std::shared_ptr::lock() is= also a non-starter, in my opinion, even though it's a couple orders of mag= nitude more obscure than vector::empty(), and has only been around since C+= +11. Hence my "If it were not too late to rename..." comment in the paper.<= /div>

The shared_mutex -> shared_timed_mutex renaming= seems to have gone as follows:
N2406 (2007-09-09) (Hinnant): sha= red_mutex is proposed for TR2. (The name comes from Boost.)  It is sti= ll absent from C++11 working draft N3337.
N3427 (2012-09-23), N3568 (2= 013-03-11), N3659 (2013-04-19) (Hinnant): shared_mutex is introduced to the= standard. N3659 is adopted into working draft N3797.
N3891 (2014-01-14)= (Sutter, Nishanov): shared_mutex is renamed to shared_timed_mutex. Adopted= at Issaquah into (current) working draft N4296.
N3961 (2014-02-25), N39= 95 (2014-05-20) (Nishanov): A coauthor of N3891 proposes a new class shared= _mutex that lacks timing functionality.

Observe that the= original attitude "let's put timeout functionality into shared_mutex" came= from Boost, and the new attitude "let's make timeout support optional" cam= e from Microsoft. This is apparently for technical reasons on Windows: they= have a fast reader-writer lock that lacks timeout support, and a heavyweig= ht one that has timeout support, so they really want a place in the standar= d library to expose the fast one. The new, untimed std::shared_mutex will p= rovide such a place.

In other words, that particul= ar renaming had solid technical reasons and the weight of Microsoft behind = it; it wasn't a purely stylistic change.  I don't think any purely sty= listic changes like empty()->is_empty() or lock()->strengthen() will = ever happen.
There might be some precedent for the Standard's pro= viding silly *synonyms* for the existing constructs, analogous to how they = made 'and' a synonym for '&&', but again, that was a change made (i= n 1991) for ostensibly technical reasons, and had the weight of IBM behind = it.
ftp://std.dkuug.dk/mirror/www.maths.warwick.ac.uk/cpp/iso/min= utes/91-0093.txt


And is there any reas= on 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 attrib= ute 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&n= bsp;a good reason, even for this particular example lol.

I think I agree that [[warn_unused_result]] = should be standardized, but again that's obviously far, far out of scope fo= r this proposal.
That proposer should look at 7.6.5 [dcl.attr.dep= recated] for the appropriate wording.

=E2=80= =93Arthur

--

---
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_2444_1542533344.1421008419367-- ------=_Part_2443_972956686.1421008419367-- .