220 36631 <9ec7a895-af7b-43d3-b47a-b7c95ed8660b@isocpp.org> article Path: news.gmane.org!.POSTED!not-for-mail From: mihailnajdenov@gmail.com Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Static analysis and the future of C++ Date: Mon, 15 Jan 2018 01:27:26 -0800 (PST) Lines: 339 Approved: news@gmane.org Message-ID: <9ec7a895-af7b-43d3-b47a-b7c95ed8660b@isocpp.org> 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_3473_221638587.1516008446901" X-Trace: blaine.gmane.org 1516008331 12430 195.159.176.226 (15 Jan 2018 09:25:31 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Mon, 15 Jan 2018 09:25:31 +0000 (UTC) Cc: mihailnajdenov@gmail.com To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBCUJ3A7GRAPRB77H6HJAKGQEHEXTWTI@isocpp.org Mon Jan 15 10:25:26 2018 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-vk0-f69.google.com ([209.85.213.69]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eb11B-0002mD-Bk for gclcip-std-proposals@m.gmane.org; Mon, 15 Jan 2018 10:25:25 +0100 Original-Received: by mail-vk0-f69.google.com with SMTP id e132sf1732057vkf.12 for ; Mon, 15 Jan 2018 01:27:29 -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=zXMu243Fy+w+45xC0TrLEcSOtUcTpBJiKf3VnHY+XyM=; b=ld74Hul3T4vyxlSc44JgwE/C4nYShDVRe8GtVW8Z3mXstX+iHwSvpE7Wyd0z5BoDIc Nqv8Fo71Mlvea8cIimIyA9MtfWsrFwlqVex4fu7nU7s+CRmMYOPT2Ac5LrYj4igewiDS ZYZIXfbHsdHZaXhX5hWIB2my/8EL6eKV5CqAM3fh413UpRZANv7eATlGwCiVJXf3M8xc rdBKCEk2goQZKh3DrRJ0lmCayTpCQ39v5MUJD3fEaD+fuWlnay4l9TdkXV8yy+2ndJLP elw7GvC9HnYF89P3M+JcHkWyInmfMEct/YM0gqGORXu1gvjWVX+ipOD6lDvBCYoUSpuj nQLQ== 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=zXMu243Fy+w+45xC0TrLEcSOtUcTpBJiKf3VnHY+XyM=; b=hlqGKDCuRSXqu3XA77DRyTB5yiejo4PztZZ+PBGetUj2ikPp7Gh014+VTU+ViQKYg+ bMQDpsLcYPMpBAPEXnwFTRmg9w7R/XBugo4qWIQOOBW3R7Yb8uiRVzdeeHS/Xlmr3MBt kxjN8h46308cw9sOXqNG9juq4ypEuSGb2Nf6l54F3SU3VJ/j2KTOq+pdIAF3uBXf0KlA XbrMWPgN7Y4RMibf9hrSLaHCLfKW9oXeBGnW42eNS2eCPY5NRj60qhe7X3ghTrkoCz/M ODOQulIjnTiTb+Ly8n6rZpy1T71Fja/jH9AFgPSk/QB4/wGobawA2TVbqVI1X5klpNtm 6SOw== 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=zXMu243Fy+w+45xC0TrLEcSOtUcTpBJiKf3VnHY+XyM=; b=Bd7u45O8yYiN7JMVpT/nOysIivk1XyEVfFjiEdHL661JA+uP6TWik9S2RO1cNRT0WY OGxOnMZXDQ7a1CAnHNbG+/5fIUMXNFzHn9YfP98UGjxRHFaNu1lWWppgpHb5Oe4TAADH DRkaIsx26PrhGCBvhWR8tBK6Z3f5Qx/SbihYp/OMhfeL/wOYcvW0zjKBthef1HKD65h+ cm5HxixGoCCZRTjd6xp6cyoBCrLDGBEteT8+ngWGLL1Gd1YZiIeiUDqPuTWWOgnLPnDp Sk0rBgz3xI8eRvt7VTQmb5xjXxGQyb5/ypGAtHoip5jeNETUk+rHMBL8+R787PYm68dM sSeA== X-Gm-Message-State: AKwxytdpV1/DtDURtyNbSI3nGVuQ36zGxYIa0DaeGdqw7cliMRn1Ognz etsuarvubyx49dV9hojDTtJDew== X-Google-Smtp-Source: ACJfBoveCq9QjjiRfws7RwCRPMm52ZlYHQTJB934pANmlhTt/RFxAERqczB1kcGPG5mEArzs0NOhhg== X-Received: by 10.31.7.12 with SMTP id 12mr1442412vkh.71.1516008449055; Mon, 15 Jan 2018 01:27:29 -0800 (PST) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.31.5.8 with SMTP id 8ls72165vkf.12.gmail; Mon, 15 Jan 2018 01:27:27 -0800 (PST) X-Received: by 10.31.162.200 with SMTP id l191mr3710887vke.14.1516008447450; Mon, 15 Jan 2018 01:27:27 -0800 (PST) In-Reply-To: X-Original-Sender: MihailNajdenov@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:36631 Archived-At: ------=_Part_3473_221638587.1516008446901 Content-Type: multipart/alternative; boundary="----=_Part_3474_360892104.1516008446901" ------=_Part_3474_360892104.1516008446901 Content-Type: text/plain; charset="UTF-8" On Monday, January 15, 2018 at 1:54:32 AM UTC+2, Nicol Bolas wrote: > > > > 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{}); > > You are not fair in your example. I was very specific - the attr will be ignored for heap allocated views (which are not that widely used, if at all). In any case an attribute can be ignored - it is just a hint - it is whole different story if its an language extension. However, even for heap allocated views it will be *possible* to give a warning if view is used after A is destroyed, where it is practically impossible to extend the lifetime of 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. > You have to give me an example, I am not sure I understand the issue. My logic is very, very simple - as long as we have automatic variables (aka predictable destruction) the compiler knows *everything* needed to track improper use, given our specification of improper use. Temporaries, prvalues these have semantic value to us, but in the end - it is the compiler just rearranging the calls the dtors. All is visible to him - he created it. If we, in this predictable for the compiler world, want a variable marked so we are informed it is used before another variable from this same predictable world, I am pretty sure the compiler can do this for us. The point is, not want *can't* be done (the cases which will not be possible), but what *can* be done. Covering the trivial cases alone is not only better then nothing, but will actually amount to 95% of the cases needed to be covered in the first place. > > 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. > Does not change the fact the standard not mandating warnings, it is the implementation which must take the initiative - warning for assignment in if statement, warning for no return, for fallthrough, for empty statements, etc etc. These save lifes for pros and juniors alike. Ironically all the standard did is a way to turn these warnings off if they do not match the intend. However, how about the standard turning warnings on (in cases impl. agree are implementable). Granted [[deprecated]] is such an example but, that is way too little, compared to what it is possible. Sure it is better to make this code illegal, but what if it is not possible or too hard? As the saying (in my language) goes - [*It is] better [to have a]sparrow in the hand, then an eagle in the sky.* -- 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/9ec7a895-af7b-43d3-b47a-b7c95ed8660b%40isocpp.org. ------=_Part_3474_360892104.1516008446901 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Monday, January 15, 2018 at 1:54:32 AM UTC+2, N= icol Bolas wrote:


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 wrot= e:
On Sunday, Janua= ry 14, 2018 at 11:34:42 AM UTC-5, mihailn...@gmail.com wrote:
On Sunday, January 14, 20= 18 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 s= hould 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?=C2=A0
<= br>
If attributes aren't "about the language", then= why are they defined by the language? And how do you explain P0840?=

...
<= div>
You're thinking about it backwards. If people freque= ntly 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" i= ts problems?

I don't find t= he possibility of adding lifetime extensions realistic.=C2=A0 I don't m= ind 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 problems - we break our own rules addi= ng that. Yea, const ref already breaks it, but still. Even semantically is = not very accurate - a view is 'slave' to the viewed, should not con= trol it.
Also, what will happen with heap allocated views? Will t= hey fail to compile and be illegal?=C2=A0

But as I= said, I will not fight against lifetime extensions, I just don't see t= hem coming. Ever.
Where with said = attribute we can considerably improve the quality of the user code, = making the foot gun very loud.
=C2=A0
Except where it doesn't, of course:

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


You are not fair in your example. I was very spe= cific - the attr will be ignored for heap allocated views (which are not th= at widely used, if at all). In any case an attribute can be ignored - it is= just a hint - it is whole different story if its an language extension.

However, even for heap allocated views it will be possible to give a warning if view is used after A is destroyed, where= it is practically impossible to extend the lifetime of A!
=C2=A0=
=C2=A0
After a discussion about the "extend me" proposal = idea, I investigated the issues with an annotation-based approach. I conclu= ded 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). Whi= ch 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 creatin= g the prvalue, it stops being a prvalue. So unless the immediate scope know= s that the parameter is going to be used like this, it can't be annotat= ed properly.

You have to give m= e an example, I am not sure I understand the issue.

My logic is very, very simple - as long as we have automatic variables (= aka predictable destruction) the compiler knows everything needed to= track improper use, given our specification of improper use.
Tem= poraries, prvalues these have semantic value to us, but in the end - it is = the compiler just rearranging the calls the dtors. All is visible to him - = he created it.

If we, in this predictable for the= compiler world, want a variable marked so we are informed it is used befor= e another variable from this same predictable world, I am pretty sure the c= ompiler can do this for us.

The point is, not want= can't be done (the cases which will not be possible), but what = can be done. Covering the trivial cases alone is not only better the= n nothing, but will actually amount to 95% of the cases needed to be covere= d in the first place.

=C2=A0

Ultimatel= y, I've come to believe that the only reasonable solution is something = like `extend_me`: something which explicitly extends the lifetime of a temp= orary, 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 veri= fy). 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 unexpe= cted but clearly explicitly specified.

Does not change the fact the standard not mandating warnings, it is= the implementation which must take the initiative - warning for assignment= in if statement, warning for no return, for fallthrough, for empty stateme= nts, etc etc. These save lifes for pros and juniors alike.=C2=A0
=
Ironically all the standard did is a way to turn these warni= ngs off if they do not match the intend. However, how about the standard tu= rning warnings on (in cases impl. agree are implementable).
Gran= ted [[deprecated]] is such an example but, that is way too little, compared= to what it is possible.


Sure it is= better to make this code illegal, but what if it is not possible or too ha= rd? As the saying (in my language) goes - [It is] better [to have a]sparrow in the hand, then an eagle in the sky.

--
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/9ec7a895-af7b-43d3-b47a-b7c95ed8660b= %40isocpp.org.
------=_Part_3474_360892104.1516008446901-- ------=_Part_3473_221638587.1516008446901-- .