220 36615 <0087c1a4-0b36-40ca-8d43-5bfaf0af62ca@isocpp.org> article Path: news.gmane.org!.POSTED!not-for-mail From: mihailnajdenov@gmail.com Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Static analysis and the future of C++ Date: Sun, 14 Jan 2018 05:40:26 -0800 (PST) Lines: 213 Approved: news@gmane.org Message-ID: <0087c1a4-0b36-40ca-8d43-5bfaf0af62ca@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_2486_289920278.1515937226810" X-Trace: blaine.gmane.org 1515937111 4510 195.159.176.226 (14 Jan 2018 13:38:31 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sun, 14 Jan 2018 13:38:31 +0000 (UTC) To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBCUJ3A7GRAPRBS535XJAKGQEZUEFIDI@isocpp.org Sun Jan 14 14:38:27 2018 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-vk0-f72.google.com ([209.85.213.72]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eaiUT-0000hk-HY for gclcip-std-proposals@m.gmane.org; Sun, 14 Jan 2018 14:38:25 +0100 Original-Received: by mail-vk0-f72.google.com with SMTP id 18sf6263072vkk.15 for ; Sun, 14 Jan 2018 05:40: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:message-id:subject:mime-version:x-original-sender :reply-to:precedence:mailing-list:list-id:list-post:list-help :list-archive:list-subscribe:list-unsubscribe; bh=+6Tb7dIFLv/Qkm8+rid7XySOxwXiNDb5SEcnXTqkjaQ=; b=YJC0B0epjtRjyJmiutm/aJOn2ND4UkzwHrSW+NavAAGWPggYNLN1KsoW8bdQGxc3zp dxVvRmUJo/okl0047U996wZS9D3feKwcQHWKX4Ix7gnVNmQj64DhpbfEZGRZJKQjR1ZH akcEGyGBRqOzAo9ATS1LskZxWsOKYHqZ5AatfGqNL/GsvkBLfLMaulSGBCDs00zsTwdq zSEqmO0o1V/W+ET0N5TcYvDVVHcY/8V3mVZAApT0kiO1x1Sdo2V+EZ3zvGWYvtp54l+5 OoaIN+EOUajEeaCrB4Ffxqfgnhaxmi9dsTLyGrXfPpiS1zwuwoOiLEtMwV283iF5cjIO QxcQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:message-id:subject:mime-version:x-original-sender :reply-to:precedence:mailing-list:list-id:list-post:list-help :list-archive:list-subscribe:list-unsubscribe; bh=+6Tb7dIFLv/Qkm8+rid7XySOxwXiNDb5SEcnXTqkjaQ=; b=b/Vz7OFAoY7CXf/oxOV3VGyNGkO5I3pLXCjw4lXOju3mb7Gn9mC/KxCRYEs6OP7gjD +t9xSayl3SgDgdV4Nv1goBY/xBU2zLPBExXxOsiy4e5CY3GX9LeOft+sAKP33ZnX4XSv 8lgZgy3veRe5YgG/edHRWTQIm9ZYJNvOcaMzSwy1oJMINxE3G0XMOuwiCTNf3vCs+T6q 0G/L8WM8MAjjQ81yW9uWFF49utnuk2DFfY7kPSHB0+k0FK3LuxLcBzqCPDA/UoY6zW12 P9BUIDVQG6EaCTAbwC0CbaxQ6fh3+OAJLh6MHjg7bJVE2ui7PMiH3utOfZrPW8gDdJsg ZWhQ== 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:message-id: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=+6Tb7dIFLv/Qkm8+rid7XySOxwXiNDb5SEcnXTqkjaQ=; b=qFtwoJYb21arxlKsnhI+w4oYK3AWBnur4lD4nb9oh4x+wxm4elyKG0Ijf+AiqupUND DYORUdvB/LhWGCf9tZelIUS4YmblkZJ6asSTR9wXc2ITtLHfl8jN6Kv2iVHny3wQZ3GV lTGXPXZy4I7gHKCCdHC8eKQmXSGNZqJsUCbNh0+0HCptk4MozEhcRf6hena9T/lOd770 et3fTkeAnLgCw3pc0/OUVIMHZ1mn+9nX+MGuheNMrz/eaSvH4bMsvmSuyA6cRkIWcpCh 0UnRJEj+JtAlFVQ8QqgjCXOo+gVeXHOGQLwwn8/R0GW+79pfcppoPQxQhr+b+YwVnoHv UEJg== X-Gm-Message-State: AKwxytcUHQsGzzBsNKkh1DHNW9d4QLesXUIa8HkT5Ld0afScqTlFtyCD EMh4ur7W+6vfxS6WWDN/G6SfAQ== X-Google-Smtp-Source: ACJfBovfzRWbMn6S/TKh93Wae0CW7ykzHgTZ0tI4zoOXUQ5GRoAf0o1AADQ7HjAun3mR8jjK1pceYg== X-Received: by 10.176.30.66 with SMTP id n2mr10960722uak.118.1515937229078; Sun, 14 Jan 2018 05:40:29 -0800 (PST) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.31.5.8 with SMTP id 8ls1536185vkf.12.gmail; Sun, 14 Jan 2018 05:40:27 -0800 (PST) X-Received: by 10.31.48.85 with SMTP id w82mr3450280vkw.11.1515937227323; Sun, 14 Jan 2018 05:40:27 -0800 (PST) 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:36615 Archived-At: ------=_Part_2486_289920278.1515937226810 Content-Type: multipart/alternative; boundary="----=_Part_2487_326759207.1515937226811" ------=_Part_2487_326759207.1515937226811 Content-Type: text/plain; charset="UTF-8" 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. Now on a concrete idea - to *use static analysis to make *_view classes safe(er).* Here is a suggestion: struct A_view { A_view( [[dependent_lifetime]] A&& arg) : _a(&arg) {} A* _a; }; Now, given the code above using A_view, after ~A() is called on the variable arg points to. will be marked as an error: A_view ref(A{}); //< OK, no use of ref A_view (A{}).func(); //< OK , A outlives ref A_view ref(A{}); ref.func(); //< error/warning, ref used after A is destroyed I believed this can be enforced by *any* compiler, as* long as *these limitations apply. 1) A_view is not heap allocated 2) We forbid *all* uses of ref, not just uses involving _a; These two limitations are there to avoid tracking lifetime through pointers. Lifetime contract is exclusively b/w ref and *(&arg). Considering the compiler is responsible to destroy both of these, it *should* be possible to give a error/warning if variable ref is used after variable *(&arg) is destroyed. Copies of ref do not contribute to lifetime tracking - assumed is the view outlives the viewed the same way it is assumed when the view is created from a non-rvalue. Comments are more then welcome, both on the broader topic about mandating static analysis and the concrete proposal. Thanks Mihail Naydenov -- 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/0087c1a4-0b36-40ca-8d43-5bfaf0af62ca%40isocpp.org. ------=_Part_2487_326759207.1515937226811 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello,
In recent years there is a boom of = static analysis - from new languages like Rust and Swift to the powerful to= ols, 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?=C2=A0
If a tool is a lifesaver, why is it not mandatory - = who does not what to save lifes?

I strongly believ= e 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 l= ot 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).

Here is a suggestion:

= struct A_view
{
=C2=A0 A_view( [[dependent_lifetime]]=C2=A0 A&& arg) : _= a(&arg) {}
=C2=A0= A* _a;
};

Now, give= n the code above using A_view, after ~A() is called on the variable arg poi= nts to. will be marked as an error:

A_view ref(A{}); //< OK, no use of ref

A_view (A{}).func(); //< OK , A outlives = ref

A_view ref(A{});
ref.func(); //< error/warning, ref use= d after A is destroyed

I believed this can be enf= orced by any compiler, as long as these limitations apply.
1) A_view is not heap allocated=C2=A0
2) We forbid all uses of ref<= /font>, not just uses involving _a;

These two limi= tations are there to avoid tracking lifetime through pointers.
Lifetime contract is exclusively b/w ref and *(&arg).=C2=A0
Considering the compiler is responsible to destroy bo= th of these, it should be possible to give a error/warning if variab= le ref is used after variable= =C2=A0*(&arg) is destroyed.
Copies of ref do not contribute to lifetime trackin= g - assumed is the view outlives the viewed the same way it is assumed when= the view is created from a non-rvalue.
Comments are mo= re then welcome, both on the broader topic about mandating static analysis = and the concrete proposal.

Thanks=C2=A0
Mihail Naydenov

--
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/0087c1a4-0b36-40ca-8d43-5bfaf0af62ca= %40isocpp.org.
------=_Part_2487_326759207.1515937226811-- ------=_Part_2486_289920278.1515937226810-- .