220 36628 article Path: news.gmane.org!.POSTED!not-for-mail From: Nicol Bolas Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Static analysis and the future of C++ Date: Sun, 14 Jan 2018 15:54:32 -0800 (PST) Lines: 232 Approved: news@gmane.org Message-ID: References: <0087c1a4-0b36-40ca-8d43-5bfaf0af62ca@isocpp.org> <4270ffec-ccc7-4abd-836d-213db296be84@isocpp.org> <08cecc11-e902-4542-a827-53dc45a125d5@isocpp.org> <4e25f92e-bd17-42e4-9a33-68916ae380d6@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_3827_51230773.1515974072599" X-Trace: blaine.gmane.org 1515973956 23762 195.159.176.226 (14 Jan 2018 23:52:36 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sun, 14 Jan 2018 23:52:36 +0000 (UTC) Cc: mihailnajdenov@gmail.com To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBCEKFTV6ZUMBBOO357JAKGQEZE34B4A@isocpp.org Mon Jan 15 00:52:32 2018 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-ua0-f200.google.com ([209.85.217.200]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eas4l-0005ob-5c for gclcip-std-proposals@m.gmane.org; Mon, 15 Jan 2018 00:52:31 +0100 Original-Received: by mail-ua0-f200.google.com with SMTP id x25sf8161745uax.16 for ; Sun, 14 Jan 2018 15:54:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isocpp-org.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:message-id:in-reply-to:references:subject :mime-version:x-original-sender:reply-to:precedence:mailing-list :list-id:list-post:list-help:list-archive:list-subscribe :list-unsubscribe; bh=iF39fYvped0b6y2vtBigg7g7VjPuKGFq6XTPtlPwjWs=; b=fCracZkwpDK2CAA+qszFhNar5po71ipj2t6w1aKMUh53YK4/84wM/hjZ8SExsbcGqy 3K4RiYzMe9bUfBZP/Ol6i55pwTiYZQwawKmBNcZXY4txTKZ2bTfdpKI6rnaE1FW/vtFZ 7XZF159IWkqN3mVehSOHpmcOLG6A8OLBlpE3VGie0SoJ6jXuuhBagUM9SJqP+Iw0DV86 itOX473Yh6sDwWucuD/nMnxHrEV+pXGgvSE6T+yWpvTUaWyTDsgVPSmHWN6zpacDfP3T 3ZOR5YyNeRmvVs+kzHrM5iLMauvEPphVXsmvFlqhOn6aD03FH983pOvEVALs4Tua2xvS YRlw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:cc:message-id:in-reply-to:references:subject :mime-version:x-original-sender:reply-to:precedence:mailing-list :list-id:list-post:list-help:list-archive:list-subscribe :list-unsubscribe; bh=iF39fYvped0b6y2vtBigg7g7VjPuKGFq6XTPtlPwjWs=; b=sWSTbEmNyW26rlzVDo7AouTOBfu/hgOb93UDDstbRS4QWdFmrGKZ2wj9DjEAjoVB8F PUQPHxDUfKXn14x8yN/Gm59MnA6kbDxSkLmowFhMwTukh7O5K3DN6S9E+pihmSvAcXH6 ps0q6XORHfFzGN8W3+jRUfCjylwm4AhsYUZP+wY5OyKONVXQNA8MiiKwq1MKmPQR40lK MuzLF6TXek5aFE1mTmYC0wz0S6+m+HBIAwZDRnqxsUZPa9uU45y3+eRhw13tBfP/8sLV nEHHMGcs+6EX/B9iiDF/oBR+DN7tUn/5KCZwiEH6cV0yOXboLOT5YVwE2NexEhgiyHT0 oEGQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc: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=iF39fYvped0b6y2vtBigg7g7VjPuKGFq6XTPtlPwjWs=; b=dHLTg1n/B7pZmrjnzfE01MbETHTT03amf9zUSs+/JA/Ls+e+3vQM8mK5titBIDSy81 P72NFChrv3G4cxxMlUi1/Y/VSIaH8SN9JxRgfAQWJpDxs8ECIiIPDS3vR29qrx7cbW55 FVjk7LPjCGzPs+VJFgRHWLjdlimNriFuSNEa26kSPCJPtf85woBMIqcpBOBCGpbKrITM Pod8QlEVxCdtTHvQtf5U5nK9903xWLgymX5iG6vXV11dhacHjEQdRb/LMoTmPsy80ffI EHlpCMPP+5Stkdsf0apijN6skWC5UQc4eb08abRhTSq+h3QvKBT7VKSxYrpVbUmknUqQ Jn0A== X-Gm-Message-State: AKwxytf8d8NSVz1mnsNQ8DaKhRmoJH6yA99gISQkmzt/bWPdHxVpRQSr 6A3OZDa9FrA2zyUu4AmMG4774g== X-Google-Smtp-Source: ACJfBouuHvd5KRh65M+UUby5R5DsiULTrRBdR8eRhkjskJK+wVEU5KuNP15KODgaSbgRviTkBIqgFQ== X-Received: by 10.31.106.71 with SMTP id f68mr14539468vkc.10.1515974074784; Sun, 14 Jan 2018 15:54:34 -0800 (PST) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.159.38.164 with SMTP id 33ls2018045uay.19.gmail; Sun, 14 Jan 2018 15:54:33 -0800 (PST) X-Received: by 10.31.4.9 with SMTP id 9mr3583831vke.7.1515974073146; Sun, 14 Jan 2018 15:54:33 -0800 (PST) In-Reply-To: X-Original-Sender: jmckesson@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:36628 Archived-At: ------=_Part_3827_51230773.1515974072599 Content-Type: multipart/alternative; boundary="----=_Part_3828_1894541883.1515974072599" ------=_Part_3828_1894541883.1515974072599 Content-Type: text/plain; charset="UTF-8" On Sunday, January 14, 2018 at 3:44:10 PM UTC-5, mihailn...@gmail.com wrote: > > > > On Sunday, January 14, 2018 at 9:05:44 PM UTC+2, Nicol Bolas wrote: >> >> On Sunday, January 14, 2018 at 11:34:42 AM UTC-5, mihailn...@gmail.com >> wrote: >>> >>> On Sunday, January 14, 2018 at 6:03:45 PM UTC+2, Nicol Bolas wrote: >>>> >>>> ... >>>> ... >>>> >>> >> And it's that "difference" that I'm saying shouldn't happen. If you want >> a static analyzer to find bugs, that's great. But the standard should not >> require it, nor should the standard be getting in the way of that process. >> > >> The standard should be about the actual language. >> > > Yeah, but things like attributes are not about the language. And that is > OK. If there is an attribute which will help you enforce correct code, why > not have it? > If attributes aren't "about the language", then why are they defined* by the language*? And how do you explain P0840? .... >> >> You're thinking about it backwards. If people frequently keep writing >> code like that, then on some level, they want to write it that way. It's >> natural for them to. So you can either slap them in the face and make them >> stop, or you can just* make it legal* and make it do what they expect. >> >> Yes, making it legal properly is infinitely harder than just slapping an >> attribute on it and calling it a day. But why should C++ keep taking the >> easy path to "fixing" its problems? >> > > I don't find the possibility of adding lifetime extensions realistic. I > don't mind it, but I really, really doubt it will ever be added. Is there > any work on in that direction? Have ever been any work on that? > Yes there has . But apparently, EWG didn't consider the cost of consistent use of such annotations to be worth the fixing of this problem .. Not that it is without problems - we break our own rules adding that. Yea, > const ref already breaks it, but still. Even semantically is not very > accurate - a view is 'slave' to the viewed, should not control it. > Also, what will happen with heap allocated views? Will they fail to > compile and be illegal? > > But as I said, I will not fight against lifetime extensions, I just don't > see them coming. Ever. > Where with said attribute we can *considerably* improve the quality of the > user code, making the foot gun very loud. > Except where it doesn't, of course: auto ptr = make_shared(A{}); After a discussion about the "extend me" proposal idea, I investigated the issues with an annotation-based approach. I concluded that the only way to make it work would be to add the equivalent of a* third* reference type (whether you spell it with `&&&` or some keyword or attribute associated with a reference parameter, the effect is to have a thing which behaves much like a third kind of reference). Which means you'd have to make forwarding references work with such a tool... somehow. Your attribute-based annotation falls into the same trap: once you leave the immediate scope of the code creating the prvalue, it stops being a prvalue. So unless the immediate scope knows that the parameter is going to be used like this, it can't be annotated properly. Ultimately, I've come to believe that the only reasonable solution is something like `extend_me`: something which explicitly extends the lifetime of a temporary, which is the responsibility of the writer of the prvalue expression to properly use. Actually I will not be surprised if implementations start doing that by > themselves (warning in cases thy can verify). The question is, why the > initiative should always come from them? > Because the interaction between two rules of the standard makes this legal code behave in a way that is unexpected but clearly explicitly specified. -- 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/a4ce1aca-9445-4557-b2d9-478e027bf0a0%40isocpp.org. ------=_Part_3828_1894541883.1515974072599 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Sunday, January 14, 2018 at 3:44:10 PM UTC-5, m= ihailn...@gmail.com wrote:


On Sunday, January 14, 2018 at 9:05:44 PM UTC+2, Nicol= Bolas wrote:
On Su= nday, January 14, 2018 at 11:34:42 AM UTC-5, mihailn...@gmail.com wr= ote:
On Sunday, Jan= uary 14, 2018 at 6:03:45 PM UTC+2, Nicol Bolas wrote:
...
...

And it's that "diffe= rence" that I'm saying shouldn't happen. If you want a static = analyzer to find bugs, that's great. But the standard should not requir= e it, nor should the standard be getting in the way of that process.
<= /div>
=

The standard should be about the actual language.
=

Yeah, but things like attributes are= not about the language. And that is OK. If there is an attribute which wil= l help you enforce correct code, why not have it?=C2=A0

If attributes aren't "about the language&= quot;, then why are they defined by the language? And how do you exp= lain P0840?

...

You're thinking about it backwards. = If people frequently keep writing code like that, then on some level, they = want to write it that way. It's natural for them to. So you can either = slap them in the face and make them stop, or you can just make it legal<= /i> and make it do what they expect.

Yes, making i= t legal properly is infinitely harder than just slapping an attribute on it= and calling it a day. But why should C++ keep taking the easy path to &quo= t;fixing" its problems?

I = don't find the possibility of adding lifetime extensions realistic.=C2= =A0 I don't mind it, but I really, really doubt it will ever be added. = Is there any work on in that direction? Have ever been any work on that?


Not that it is without pr= oblems - we break our own rules adding that. Yea, const ref already breaks = it, but still. Even semantically is not very accurate - a view is 'slav= e' to the viewed, should not control it.
Also, what will happ= en with heap allocated views? Will they fail to compile and be illegal?=C2= =A0

But as I said, I will not fight against lifeti= me extensions, I just don't see them coming. Ever.
Where with said attribute we can c= onsiderably improve the quality of the user code, making the foot gun v= ery loud.
=C2=A0
Except where it doe= sn't, of course:

auto<= /span> ptr =3D make_shared<A_view>(A{});

After a disc= ussion about the "extend me" proposal idea, I investigated the is= sues with an annotation-based approach. I concluded that the only way to ma= ke it work would be to add the equivalent of a third reference type = (whether you spell it with `&&&` or some keyword or attribute a= ssociated with a reference parameter, the effect is to have a thing which b= ehaves much like a third kind of reference). Which means you'd have to = make forwarding references work with such a tool... somehow.

=
Your attribute-based annotation falls into the same trap: once y= ou leave the immediate scope of the code creating the prvalue, it stops bei= ng a prvalue. So unless the immediate scope knows that the parameter is goi= ng to be used like this, it can't be annotated properly.

=
Ultimately, I've come to believe that the only reasonable so= lution is something like `extend_me`: something which explicitly extends th= e lifetime of a temporary, which is the responsibility of the writer of the= prvalue expression to properly use.

Actually I will not be su= rprised if implementations start doing that by themselves (war= ning in cases thy can verify). The question is, why the initiative should a= lways come from them?

Because t= he interaction between two rules of the standard makes this legal code beha= ve in a way that is unexpected but clearly explicitly specified.
=

--
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/a4ce1aca-9445-4557-b2d9-478e027bf0a0= %40isocpp.org.
------=_Part_3828_1894541883.1515974072599-- ------=_Part_3827_51230773.1515974072599-- .