220 36620 article Path: news.gmane.org!.POSTED!not-for-mail From: Jake Arkinstall Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Static analysis and the future of C++ Date: Sun, 14 Jan 2018 16:06:44 +0000 Lines: 162 Approved: news@gmane.org Message-ID: References: <0087c1a4-0b36-40ca-8d43-5bfaf0af62ca@isocpp.org> <3d1ee12f-b97a-f259-b98a-831153b4245e@gmail.com> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="001a113b0938244c820562beaf67" X-Trace: blaine.gmane.org 1515945891 21765 195.159.176.226 (14 Jan 2018 16:04:51 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sun, 14 Jan 2018 16:04:51 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBDCZX3WUUQFRBFUA53JAKGQE7PFQH2Q@isocpp.org Sun Jan 14 17:04:47 2018 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-oi0-f72.google.com ([209.85.218.72]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eakm3-0005BQ-3b for gclcip-std-proposals@m.gmane.org; Sun, 14 Jan 2018 17:04:43 +0100 Original-Received: by mail-oi0-f72.google.com with SMTP id s5sf850179oib.7 for ; Sun, 14 Jan 2018 08:06:47 -0800 (PST) ARC-Seal: i=2; a=rsa-sha256; t=1515946006; cv=pass; d=google.com; s=arc-20160816; b=WduoW5Trv/mZ2+PvR0+XWLBYqe6TY8LBXVXkiPpfF3PEKm4EeKgryWCqUo1ZgdM7gf 4doZt4HaUUBWgQK48wwW34AdRHgJ/SZgWoU6M4DX7cYOocOtS8Pd3iUZ+Tg2ZKGIg40/ QjAkNsJ9lWb5LYjfDcuZDtpZqOXNy4cC6VTwhFc9VT1bKd+getF814OkjbX4iIT72SA2 GXEPQ0KLYKbpKVnzN/QToO8YJkROkjA0pfksu17i71FZKaLWRl68o9LRS6xD1+u47jXN hgDlpSFnLg6pdPI76oiqYIUbT2zrOtUEB+RyemX3AmxGW4n+s9XxfcTnt5bR4U1nQX69 VRCQ== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:reply-to:to:subject:message-id:date :from:references:in-reply-to:mime-version:arc-authentication-results :arc-message-signature:dkim-signature:arc-authentication-results; bh=iAeZakR1pFSf4i8RRiqhdNPFX0EuLpKaFv623EelA/U=; b=KigqwLIQZ5qqcQ9vtyY8I42tGFw06Mn/o0dywPSvcj+/ueRJ7X4HOsBfRH5SDRx8ua ZROcapBdv2J8y2m53wdTKl/sANs82yuza6DsCQsjAJ4MfpJQqwtDysx4nb8QV0TY/2yR EQD2k37bGg/OVB6P33ZZ95DJKSqND8j/E/4aLSujpSGYeflWdBza3UKHj3a8NLpwilPL U7mO7pqMqmPyDvfB5h+m6g6rmSeYN3LAZf/RKMxmeTwNd19bsG/Y40VXbRPbgXe8eLUX THhUZ6VEj2YGtfilEK1oeSS0hzjkbGowEwkWgR3Gdin4VIRXOCIg2pd/lOOKYariajQb 0O2w== ARC-Authentication-Results: i=2; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=tBNaIw2r; spf=pass (google.com: domain of jake.arkinstall@gmail.com designates 209.85.220.65 as permitted sender) smtp.mailfrom=jake.arkinstall@gmail.com; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=gmail.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isocpp-org.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :x-original-sender:x-original-authentication-results:reply-to :precedence:mailing-list:list-id:list-post:list-help:list-archive :list-subscribe:list-unsubscribe; bh=iAeZakR1pFSf4i8RRiqhdNPFX0EuLpKaFv623EelA/U=; b=LtsiPcqjwP1VFjsKxc1X9fGirPw2f9TlIKiJw/16mr/CnR3IN4q5sOR/v/3ra4nrpb bBy/gj2AhQvfuLOAL0xJhUobUHcftzCG9z9mvVEH9NlgHWZ7WxKf9ehk8hOS40J/EooB cMHWZr160rouEEwui5aggB6I2dcftqzK2gL/KBfZ/c28wR8bC1PiRzLSVfOPcPCuCKJQ CDO1ubCEBR2SuI/On8wA7sNtS+RJWIH0R73w06Tngbs6WBadiKgIHJP8oHurvGK7vk6X DYH8gsyXaEqaCYy0lx8JtolAU8BR0kwVobyJEyA8w19eysZbrb30ulfH0nkQvA752XJD pZ7Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:x-original-sender :x-original-authentication-results:reply-to:precedence:mailing-list :list-id:x-spam-checked-in-group:list-post:list-help:list-archive :list-subscribe:list-unsubscribe; bh=iAeZakR1pFSf4i8RRiqhdNPFX0EuLpKaFv623EelA/U=; b=s2VRgMhGl3SulPjEq9tjx2l9M+3//HN3XM0BK7nZm5XUdcnYAz33C5gjzbY4GZ1oR4 mnpAG4GwrP2LByrrfPS8V8ClCFLXc3Hrn6CAMrz6nN4gBYjGz3SHz/K0AmRWfCIUN1ZW KQJ1n/cckFyiGym0Zg1ZduzvZ8bJyL5xhHxgb385AucAMVok2zAoWttYuUrCLBrSA1K4 ZNH3M0vQD/KPpnalErSzm0Z6vHr0RqPXHMM/2XRwzGYx77HEdqLcylOChcJ70hcbX1oW qjaB79X2R65P56Yyk5z+8MldcJA40DPeIfQzS8hBpGL1ze+QZ7qdCPiDonUzhP5ri+fA WafA== X-Gm-Message-State: AKwxytejjH8kAq2jr/A/Hp0RC5g3olGDBrldmCVj6q1NvDakxEo6Ty9F zjQtQDXE9fLtGo/kecxJRvTnKg== X-Google-Smtp-Source: ACJfBovDeAdotvM56mZmoyrvROi1aGA/yBnZwTATwMSOC6LfwdlNSmGUriuqNdtSTorpDIaHylg66A== X-Received: by 10.157.50.21 with SMTP id t21mr894833otc.94.1515946006776; Sun, 14 Jan 2018 08:06:46 -0800 (PST) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.157.24.27 with SMTP id b27ls1983023ote.9.gmail; Sun, 14 Jan 2018 08:06:45 -0800 (PST) X-Received: by 10.202.192.214 with SMTP id q205mr10505089oif.313.1515946005682; Sun, 14 Jan 2018 08:06:45 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1515946005; cv=none; d=google.com; s=arc-20160816; b=Bj0qtuVxnpNLYrrxK6xZV2ScAo4y/4OqVMApNPO/lJJYl1zaUtbMbPrLSXd9K5xWAU e3C7ySQQzsx9N4NwKuA5IOPu6xww7i8qNcAiOMdAg28vn16L5a0f2Qv+yQvH3l5DRTBo Rk18RVLJN5bE36gMv1485ZdKfua+tobrrxY7hgCCRiOey2HPi9pN/hom4jekT/j71bO3 tQxIMnnlmW5XZaZc2BxKfbofSK6wg+2HTZcoevtqJChuahVk4TvRguM15cXaBnAslTKj 0grgH9pAZNLNbAv9aFTGelIQTJrLS5s4gotb4TtK7eupye1E0NWlradg98NusuQT1c4j 1/bA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=to:subject:message-id:date:from:references:in-reply-to:mime-version :dkim-signature:arc-authentication-results; bh=oJ34PC35HGKkMbI54d/kcN0QjWYfNp0lB/BfbCNjY3g=; b=zIF3Zca34I9+7JttCMM4J9LMfwi1j4OdlWe9kRpWU/C/AV4UsFeycoxaWD08LBdINS uX/J1nSEfHhYCxXiEDWBLe7PLlM3ToviGK8wpg/bMkJtsVHcKSTIwPhwXIXcH9gJxVHE jBrOVzZpoZ4ueACF8/ntToXTUSA0j3bC3n4EyRUHB2ZbiNvuNhA5WUM2l/VcgTROyxeN rBZAjbmWb5lUfYAQbdbdlcM2YprtZ5FbsWCISZhEwX2cRv3K6PJV8h0qvnSigv7E3To7 Hqt5lrxggvyUTyY/iVn/tR8BUf2eEVaXoq4XBoAfkcoN1xtS7vFk3DGQHodzWi0rsM7X LG9w== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=tBNaIw2r; spf=pass (google.com: domain of jake.arkinstall@gmail.com designates 209.85.220.65 as permitted sender) smtp.mailfrom=jake.arkinstall@gmail.com; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=gmail.com Original-Received: from mail-sor-f65.google.com (mail-sor-f65.google.com. [209.85.220.65]) by mx.google.com with SMTPS id u132sor5054395oia.150.2018.01.14.08.06.45 for (Google Transport Security); Sun, 14 Jan 2018 08:06:45 -0800 (PST) Received-SPF: pass (google.com: domain of jake.arkinstall@gmail.com designates 209.85.220.65 as permitted sender) client-ip=209.85.220.65; X-Received: by 10.202.84.77 with SMTP id i74mr13338166oib.79.1515946005251; Sun, 14 Jan 2018 08:06:45 -0800 (PST) Original-Received: by 10.168.69.140 with HTTP; Sun, 14 Jan 2018 08:06:44 -0800 (PST) Original-Received: by 10.168.69.140 with HTTP; Sun, 14 Jan 2018 08:06:44 -0800 (PST) In-Reply-To: <3d1ee12f-b97a-f259-b98a-831153b4245e@gmail.com> X-Original-Sender: jake.arkinstall@gmail.com X-Original-Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=tBNaIw2r; spf=pass (google.com: domain of jake.arkinstall@gmail.com designates 209.85.220.65 as permitted sender) smtp.mailfrom=jake.arkinstall@gmail.com; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=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:36620 Archived-At: --001a113b0938244c820562beaf67 Content-Type: text/plain; charset="UTF-8" I don't think the idea is to force users to do it, but to force compilers to do it. It's essentially the same as deprecating various forms of undefined behaviour, which in turn forces compilers to become smarter. My position on this is constantly evolving. On one hand it's nice to have a language that doesn't allow developers to screw up. On the other hand, it's also nice to allow users to have more control (which is why std::unreachable is favourable to me, so that people only get more control when they ask for it). I do not believe it is reasonable to *demand* compilers check for such things simply because it isn't currently reasonable to demand users to do such things. I do, however, think it'd be very useful for every teacher of C++ (From tutorials to books to actual teachers) to explicitly teach people what tools are available to them. When I first started out with C++, I made so many dumb mistakes that took a long time to figure out. Sure that process made me a better developer, but it would have been a lot easier had my toolset been better than valgrind and gdb. Now we have all of these shiny sanitisers, we should mandate that new users have them drilled into their heads. In fact, I'd go as far as saying we should probably have a set of standards for C++ teaching material (I'm not sure if that's a thing). On 14 Jan 2018 15:51, "Andrey Semashev" wrote: On 01/14/18 16:40, mihailnajdenov@gmail.com wrote: > Hello, > In recent years there is a boom of static analysis - from new languages > like Rust and Swift to the powerful tools, provided by C++ compilers. > > However I don't see it C++ language /mandating/ any of these. 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. > How does *mandating* a particular tool help language users? If you can use a tool right now, why do you want to enforce it on everyone? Also, what should we do about the platforms where such tools are not available? -- 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/is ocpp.org/d/msgid/std-proposals/3d1ee12f-b97a-f259-b98a- 831153b4245e%40gmail.com. -- 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/CAC%2B0CCPnXD65H1sy_Zsx%3DYWDzhfhhSr8KAeQ6emU0f69%2Bu%3D%2B7Q%40mail.gmail.com. --001a113b0938244c820562beaf67 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I don't think the idea is to force users to do i= t, but to force compilers to do it. It's essentially the same as deprec= ating various forms of undefined behaviour, which in turn forces compilers = to become smarter.

My po= sition on this is constantly evolving. On one hand it's nice to have a = language that doesn't allow developers to screw up. On the other hand, = it's also nice to allow users to have more control (which is why std::u= nreachable is favourable to me, so that people only get more control when t= hey ask for it).

I do no= t believe it is reasonable to *demand* compilers check for such things simp= ly because it isn't currently reasonable to demand users to do such thi= ngs. I do, however, think it'd be very useful for every teacher of C++ = (From tutorials to books to actual teachers) to explicitly teach people wha= t tools are available to them. When I first started out with C++, I made so= many dumb mistakes that took a long time to figure out. Sure that process = made me a better developer, but it would have been a lot easier had my tool= set been better than valgrind and gdb. Now we have all of these shiny sanit= isers, we should mandate that new users have them drilled into their heads.= In fact, I'd go as far as saying we should probably have a set of stan= dards for C++ teaching material (I'm not sure if that's a thing).

On= 14 Jan 2018 15:51, "Andrey Semashev" <andrey.semashev@gmail.com> wrote:
On 01/14/18= 16:40, mihai= lnajdenov@gmail.com wrote:
Hello,
In recent years there is a boom of static analysis - from new languages lik= e Rust and Swift to the powerful tools, provided by C++ compilers.

However I don't see it C++ language /mandating/ any of these. I have a = question - is this something the committee is looking into? Is there a work= ing group for this?

If a tool is a lifesaver, why is it not mandatory - who does not what to sa= ve lifes?

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

Any answers and thoughts are welcome.

How does *mandating* a particular tool help language users? If you can use = a tool right now, why do you want to enforce it on everyone?

Also, what should we do about the platforms where such tools are not availa= ble?


--
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-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/3d1ee12f-b97a-f259-b98a-= 831153b4245e%40gmail.com.

--
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/CAC%2B0= CCPnXD65H1sy_Zsx%3DYWDzhfhhSr8KAeQ6emU0f69%2Bu%3D%2B7Q%40mail.gmail.com= ..
--001a113b0938244c820562beaf67-- .