220 36624 <4e25f92e-bd17-42e4-9a33-68916ae380d6@isocpp.org> 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 11:05:44 -0800 (PST) Lines: 221 Approved: news@gmane.org Message-ID: <4e25f92e-bd17-42e4-9a33-68916ae380d6@isocpp.org> References: <0087c1a4-0b36-40ca-8d43-5bfaf0af62ca@isocpp.org> <4270ffec-ccc7-4abd-836d-213db296be84@isocpp.org> <08cecc11-e902-4542-a827-53dc45a125d5@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_2888_1495016951.1515956744096" X-Trace: blaine.gmane.org 1515956628 27116 195.159.176.226 (14 Jan 2018 19:03:48 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sun, 14 Jan 2018 19:03:48 +0000 (UTC) Cc: mihailnajdenov@gmail.com To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBCEKFTV6ZUMBBCOU53JAKGQEFDVM35Y@isocpp.org Sun Jan 14 20:03:44 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 1eanZG-0006fS-Id for gclcip-std-proposals@m.gmane.org; Sun, 14 Jan 2018 20:03:42 +0100 Original-Received: by mail-ua0-f200.google.com with SMTP id 94sf7807699uat.10 for ; Sun, 14 Jan 2018 11:05:46 -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=PuvXoRe/6F30riDAJYIHTT90CkgXmIk/cQdNVPpBEKY=; b=w0fyc7uJW1nQSI4PlQYW9qTJgDIrCeKiI/cu21VcoNGfbawe9qAM0VC8PFzvr0x3fR reTuBP7x2LA1CDxogJ/HeHL/rc7EIIC1RUWozBwxHsh1OHbfrQDBCa2JziLSzB+4WwEQ mTTwYat5ad1E3ctcoKjqEE3XlhfRPlJlvq6LMaqpj/AmV30iqhMzQoip6/lDZAMfh+s3 RKCHJYL+jIgx+6rv6P+CWM+WuThr9L/p6i7xNQytKt72LI0Y6lWI8P80DkcbEQsz3Xfr 4OrxrKOxqJD3jLRnUEhy9og1X5OaPrMy6EvxMJGVL5wde96mcLAZztmuCzZopFWdH5nL +rHA== 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=PuvXoRe/6F30riDAJYIHTT90CkgXmIk/cQdNVPpBEKY=; b=SqOSOljEsJRTurCEyiMy6dUJ6Zb9Z1/RoShmMFmuIgwZ6Ky3L6OMWYby5K7l+0fhBd BBoYDRkBPNwm2fUsqjrDfFQtaH7qtUPCV4IJKNwchFdw2K7Xj9lQ3qvpTyaHdnt99TcS 5aYkgL1Y95+yj7WRc3MjsBFrTkehERywSsSydh0mpgQK3JexC7lZLaFy3TkIqOQGHdG5 1tJsWblIvGojnQTOMIJhFLEhj/UcWvtaYTlP4bhNcUZtQiK6q8IP0zTmAgkvN2m9LAky rt0FcpHEuPrE9dt/AroOVu29cHWdlbgRqXF8jlGTLizOC95pxHATOJWQrjrqw2Blp5Dj f50w== 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=PuvXoRe/6F30riDAJYIHTT90CkgXmIk/cQdNVPpBEKY=; b=QVP1tNS2tBXpMMrBJI952nL84YsPmE63WLGJSQpa35wdekUygM82qyX0HV0Ib5lQhi nqgy4Az3rrCHPCYqF65zDtfnQKxAk5bls3fdAsukDWy0BmSww7uVeypSO9eBgGtOAxn8 qeZovRPv8v3YNHbW7IZchjRLs8C7RhojULHiyuZXNP7PpRmc3ife1QEcj6GM4htp2hwX oPgo27xk5VwsQ1UT+7ofBDx6sDvxg9uq6HTAh5sRfw4XEO+iJ7DWdEDyvM5evPBHKQmP 6aeWSEKkR+G6c9eMObwYCgITpat8Dbq6EFwXRdlwBNNVgESv4zm47ckDiDqYdnV97Odp 6T9A== X-Gm-Message-State: AKwxytfT+5cAWiDdASPsSWm55HfA6vT9oFyCotKLwXp3StsigbqniBBU kpepulQHQUi84uIt3cFLjBFnEg== X-Google-Smtp-Source: ACJfBovQ5vez0h1NCH2vlJkD7EpPCZbeDZy/UiadbAjMcbZgiiPfQzxa695RRvZtiIVLMamjWwJnFA== X-Received: by 10.31.148.82 with SMTP id w79mr15911519vkd.81.1515956746236; Sun, 14 Jan 2018 11:05:46 -0800 (PST) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.176.96.47 with SMTP id n15ls1865356ual.21.gmail; Sun, 14 Jan 2018 11:05:44 -0800 (PST) X-Received: by 10.31.10.199 with SMTP id 190mr3524870vkk.3.1515956744639; Sun, 14 Jan 2018 11:05:44 -0800 (PST) In-Reply-To: <08cecc11-e902-4542-a827-53dc45a125d5@isocpp.org> 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:36624 Archived-At: ------=_Part_2888_1495016951.1515956744096 Content-Type: multipart/alternative; boundary="----=_Part_2889_654526554.1515956744097" ------=_Part_2889_654526554.1515956744097 Content-Type: text/plain; charset="UTF-8" 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: >> >> ... >> >> Static analysis is for looking at what is valid language and deciding >> whether or not it's likely that the behavior your code gets is the behavior >> you actually wanted. >> > > Isn't that precisely the example I gave? A valid language, not doing what > one wanted? > Only difference, the standard should say the implementation should warn > the user if this and that. > 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. If you make a change to the language, you aren't "using static analysis"; >> you've made something *linguistically* impossible. >> >> It's like the difference between saying "we shouldn't swear" vs. removing >> swear words from the English language entirely. >> >> Whether compilers include static analysis tools, and how they are used, >> is out-of-bounds for the standard. Though you could think of contracts as a >> mechanism to make static analysis easier, that's more a useful additional >> thing that contracts do. >> >> I have a question - is this something the committee is looking into? Is >>> there a working group for this? >>> If a tool is a lifesaver, why is it not mandatory - who does not what to >>> save lifes? >>> >>> I strongly believe bringing more (any?) static analysis into the >>> language is away to keep it modern and relevant, especially, considering >>> C++ very static language and has a lot of compile-time information the >>> tools can work with. >>> >>> Any answers and thoughts are welcome. >>> >>> Now on a concrete idea - to *use static analysis to make *_view classes >>> safe(er).* >>> >> >> This is the wrong tool for the job. The ideal solution is to make such >> code *ill formed*, not to rely on "static analysis" to make compilers >> give a warning or something. >> >> Or better yet, to change the language to make such code *functional*. >> After all, if you're going to go through the effort of tagging a function >> with this attribute, why not tag it with a keyword that extends the >> lifetime of the temporary correctly? >> >> A_view(extend A&& arg) : _a(&arg) {} >> >> ... >> >> A_view ref(A{}); //A{}'s lifetime is extended to that of the >> declaration's enclosing scope. >> >> > This is infinitely more complex to implement however, also makes semantic > change to the language (hence it can not be attribute). > But more impartially, what do you rally need it? > Do you really need the lifetime extended, when one could just decl A > before view? We are worried about errors and shots in the food, I doubt we > need the extra functionality, considering the complexity. > 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 might be wrong, I also considered [[extends_lifetime]] but discarded > because the above reasons) > -- 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/4e25f92e-bd17-42e4-9a33-68916ae380d6%40isocpp.org. ------=_Part_2889_654526554.1515956744097 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
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:
...
<= br>
Static analysis is for looking at what is valid language and = deciding whether or not it's likely that the behavior your code gets is= the behavior you actually wanted.

<= div>Isn't that precisely the example I gave? A valid language, not doin= g what one wanted?=C2=A0
Only difference, the standard should say= the implementation should warn the user if this and that.

And it's that "difference" that I= 'm saying shouldn't happen. If you want a static analyzer to find b= ugs, that's great. But the standard should not require it, nor should t= he standard be getting in the way of that process.

The standard should be about the actual language.

If you make a change to the l= anguage, you aren't "using static analysis"; you've made some= thing linguistically impossible.

It's l= ike the difference between saying "we shouldn't swear" vs. re= moving swear words from the English language entirely.

=
Whether compilers include static analysis tools, and how they are used= , is out-of-bounds for the standard. Though you could think of contracts as= a mechanism to make static analysis easier, that's more a useful addit= ional thing that contracts do.

I have a question - is this something= the committee is looking into? Is there a working group for this?=C2=A0
If a tool is a lifesaver, why is it not mandatory - who does not wh= at to save lifes?

I strongly believe bringing more= (any?) sta= tic analysis into the language is away to keep it modern and relevant, espe= cially, considering C++ very static language and has a lot of compile-time = information the tools can work with.

Any an= swers and thoughts are welcome.

Now on a concrete = idea - to use static ana= lysis to make *_view classes safe(er).

This is the wrong tool for the job. The ideal= solution is to make such code ill formed, not to rely on "stat= ic analysis" to make compilers give a warning or something.
=
Or better yet, to change the language to make such code f= unctional. After all, if you're going to go through the effort of t= agging a function with this attribute, why not tag it with a keyword that e= xtends the lifetime of the temporary correctly?

A_view(extend A= && arg= ) : _a<= span style=3D"color:#660">(&arg) {}

<= span style=3D"color:#660">...

A_vi= ew ref(= A{}); //A{}= 9;s lifetime is extended to that of the declaration's enclosing scope.<= /span>


This is infinitely more complex t= o implement however, also makes semantic change to the language (hence it c= an not be attribute).=C2=A0
But more impartially, what do you ra= lly need it?
Do you really need the lifetime extended, when one c= ould just decl A before view? We are worried about errors and shots in the = food, I doubt we need the extra functionality, considering the complexity.<= /div>

You're thinking about it ba= ckwards. If people frequently keep writing code like that, then on some lev= el, they want to write it that way. It's natural for them to. So you ca= n 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 attrib= ute on it and calling it a day. But why should C++ keep taking the easy pat= h to "fixing" its problems?

(I might be wrong, I also= considered [[extends_lifetime]] but discarded because the above reasons)

--
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/4e25f92e-bd17-42e4-9a33-68916ae380d6= %40isocpp.org.
------=_Part_2889_654526554.1515956744097-- ------=_Part_2888_1495016951.1515956744096-- .