220 36619 <4270ffec-ccc7-4abd-836d-213db296be84@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 08:03:45 -0800 (PST) Lines: 304 Approved: news@gmane.org Message-ID: <4270ffec-ccc7-4abd-836d-213db296be84@isocpp.org> References: <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_2965_1898407645.1515945825171" X-Trace: blaine.gmane.org 1515945708 7870 195.159.176.226 (14 Jan 2018 16:01:48 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sun, 14 Jan 2018 16:01:48 +0000 (UTC) Cc: mihailnajdenov@gmail.com To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBCEKFTV6ZUMBBYX65XJAKGQEP4MFUBQ@isocpp.org Sun Jan 14 17:01:44 2018 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-ua0-f199.google.com ([209.85.217.199]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eakj9-0001ib-K9 for gclcip-std-proposals@m.gmane.org; Sun, 14 Jan 2018 17:01:43 +0100 Original-Received: by mail-ua0-f199.google.com with SMTP id i9sf7738766uak.13 for ; Sun, 14 Jan 2018 08:03:47 -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=HIYYzDLZY0g2zTKWcuwPkTieg+Q9YYDmxjz5ljRUGZw=; b=yzwdmogs83d2gAWbqGWLTs27CAIchNcZmbvyyhtlaN1sNwnTOQBeR7Tv8qHXFrO6Th yPfNfMzQNz7+6aysvQkifX5qlQmE1rFSsXruwWcDv/xlXx2XfkWEQlq+5iCPLkP6xfXs 94Ql2v+67OEff6rgj4IHEoHVRmA/GRKg3sDwWUJQPDYCiEYPmLeA/F/XREQE1TGmMAxl OZzhL3uqUvvATBdDx8mUlGQa1oNp2lG9KCB2bhMLusQhLkoGstJNFzIxAajOY4sETzmq 8wkE3GqB9AkEpiIA7si2AN2NB2VYZIsC9OPQg7ji34/8SYbSq55MG95XSP3c3wY/29HR jnPw== 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=HIYYzDLZY0g2zTKWcuwPkTieg+Q9YYDmxjz5ljRUGZw=; b=Q4iVytkBWHg+VfMH+QwGEDjLxHYsvMQ6KqwCkBMcaEf2BgxGMjU8llytC5AgVrwTsP Iwd20Bdzo5c2la63w6X+z5Cn+qMUqj9L4S3yUDnhlzBvoSh0MJ0rWeGjdxMTrjb02y0O PocGDy3fI3GJEz2WcNBrwvUVcg0jK/Sf1yiQCICF9p4j2N5iu9E3/sYXpPisg0gW6rFd KKXk5StJnaMPqB6xF0P+fpvF749oisL/wKg8rPJQojczrLP27qvsGgi9eRJ/siQGtUmP 9+9GuzsyhWGJ37+zVRMFKcuxpDL7lH/E/wTTRhOXFNDLduhQ2Zdhb1X9PO/TuZ5dASCc 3EyA== 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=HIYYzDLZY0g2zTKWcuwPkTieg+Q9YYDmxjz5ljRUGZw=; b=kcEPkrD84vsne+M17+Di/khQ+gNeGWB0vYh67+IZdLnXI3OpxE925vounzSL3gAzH+ CFc3FHaXMHB+zOCxl/LgMq6Tfravf+sPCZNTB6YVXpb11efo95JLEyZnY09WIVsJm716 XagT2/kVylbtjT3IMGJAgTrZjYKC8LDv6Dz4MI/BfL4CRSHtXn0vYTwee1yJj3FL6ilX qluhPZ4rxpL9uJtxo2Piab2mTw4aEDGAyvjhtXQh+bnYdlLjR4QOgLXI32gAY2gJjPdD 4MDf8Qfu+WWypLK+beBiw4t4j81Azh/Mmep+IWNFjo/4nlzh46UvHr23pCNXHla8zeR5 GISQ== X-Gm-Message-State: AKwxytfOPka7YxnzRHp9xXhMv7E5I52UV5XBNHf9RIcQV3QTqnLw95Rq 8KrD6mdYwKP6LseZuRkQQfbj4A== X-Google-Smtp-Source: ACJfBovqz3DvIMvmUC1J0hlUqCT0Ikuy55rP4a0gUGWxSQ5h90/Aa/GI4ZfQaxnT9W63+LIr9dbstg== X-Received: by 10.176.73.81 with SMTP id a17mr8768568uad.88.1515945827307; Sun, 14 Jan 2018 08:03:47 -0800 (PST) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.159.59.2 with SMTP id i2ls1730595uah.6.gmail; Sun, 14 Jan 2018 08:03:46 -0800 (PST) X-Received: by 10.31.161.69 with SMTP id k66mr3485726vke.10.1515945825758; Sun, 14 Jan 2018 08:03:45 -0800 (PST) In-Reply-To: <0087c1a4-0b36-40ca-8d43-5bfaf0af62ca@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:36619 Archived-At: ------=_Part_2965_1898407645.1515945825171 Content-Type: multipart/alternative; boundary="----=_Part_2966_810626191.1515945825172" ------=_Part_2966_810626191.1515945825172 Content-Type: text/plain; charset="UTF-8" On Sunday, January 14, 2018 at 8:40:26 AM UTC-5, mihailn...@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. > .... why would it? The standard defines behavior. The standard decides what is valid language and how it behaves. 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. 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. 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/4270ffec-ccc7-4abd-836d-213db296be84%40isocpp.org. ------=_Part_2966_810626191.1515945825172 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Sunday, January 14, 2018 at 8:40:26 AM UTC-5, mihailn..= ..@gmail.com wrote:
Hello,
In recent years there is a boom of static analy= sis - from new languages like Rust and Swift to the powerful tools, provide= d by C++ compilers.

However I don't see it C++= language mandating any of these.

<= /div>
... why would it?

The standard defines b= ehavior. The standard decides what is valid language and how it behaves.

Static analysis is for looking at what is valid lang= uage and deciding whether or not it's likely that the behavior your cod= e gets is the behavior you actually wanted. If you make a change to the lan= guage, you aren't "using static analysis"; you've made so= mething 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 us= ed, 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 add= itional thing that contracts do.

I have a question - is this so= mething 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 do= es not what to save lifes?

I strongly believe brin= ging more (any?) static analysis into the language is away to keep it modern and relev= ant, especially, considering C++ very static language and has a lot of comp= ile-time information the tools can work with.

Any answers and thoughts are welcome.

Now on a = concrete idea - to use s= tatic 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 &= quot;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 ef= fort of tagging a function with this attribute, why not tag it with a keywo= rd that extends the lifetime of the temporary correctly?

A_view(extend A&& arg) : _a(&arg) {}

...

A_view ref({}); //A{}'s lifetime i= s extended to that of the declaration's enclosing scope.
<= /div>




= Here is a suggestion:

struct A_view
=C2=A0 A_view( [[= dependent_lifetime]]=C2=A0 A&& arg) : _a(&arg) {}
<= div>=C2=A0 A* _a;
};

Now, given the code above using A_vie= w, after ~A() is called on the variable arg points to. will be marked as an= error:

A_vie= w ref(A{}); //< OK, no use of ref

A_view (A{}).func(); //< OK , A outlives ref
<= font face=3D"courier new,monospace">
A_view ref(A{});
ref.func(); //< error/warning, ref used after A is destroyed

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

These two limitations are there to a= void tracking lifetime through pointers.

Lifetime = contract is exclusively b/w ref and *(&arg).=C2=A0
C= onsidering the compiler is responsible to destroy both of these, it shou= ld be possible to give a error/warning if variable ref is used after variable=C2=A0*(&arg) is destroyed.
Copies of re= f do not contribute to lifetime tracking - assumed is the view outli= ves the viewed the same way it is assumed when the view is created from a n= on-rvalue.

<= font face=3D"arial,sans-serif">Comments are more then welcome, both on the = broader topic about mandating static analysis and the concrete proposal.

Thanks=C2=A0
Mihail Naydenov
<= /div>

--
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/4270ffec-ccc7-4abd-836d-213db296be84= %40isocpp.org.
------=_Part_2966_810626191.1515945825172-- ------=_Part_2965_1898407645.1515945825171-- .