220 36623 <08cecc11-e902-4542-a827-53dc45a125d5@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: Sun, 14 Jan 2018 08:34:41 -0800 (PST) Lines: 184 Approved: news@gmane.org Message-ID: <08cecc11-e902-4542-a827-53dc45a125d5@isocpp.org> References: <0087c1a4-0b36-40ca-8d43-5bfaf0af62ca@isocpp.org> <4270ffec-ccc7-4abd-836d-213db296be84@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_2705_599375530.1515947682020" X-Trace: blaine.gmane.org 1515947572 2598 195.159.176.226 (14 Jan 2018 16:32:52 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sun, 14 Jan 2018 16:32:52 +0000 (UTC) Cc: mihailnajdenov@gmail.com To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBCUJ3A7GRAPRBI4N53JAKGQE472FHCA@isocpp.org Sun Jan 14 17:32:48 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 1ealD6-0008Iu-Si for gclcip-std-proposals@m.gmane.org; Sun, 14 Jan 2018 17:32:41 +0100 Original-Received: by mail-ua0-f200.google.com with SMTP id e8sf7586641uam.22 for ; Sun, 14 Jan 2018 08:34:45 -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=AOguE++p6bD2DCkFUbEQln+n7q5wuFsJXcFCOHE1wDo=; b=vGDOF9O01mnc8/LKXZYKnGBRR2LHAt0M0LHc3t5yriOA4MQvaVk5paSzqNefSvjmbM 95TWKHb5hZ/HwOzqBCB6ZCeIMvJet32GbtXvW4GdkMXD1WRAcXCfyuyav0SK6kovfu2Q 7iNzn2eS53hKpEbcLl7eIzjryAwRNpxdBoCqOUU4aEaX/cM7G/hLQ7gfCAhlaUoNnT3A f3jnGsYvZIFTn+F4wdNlQI8U30ONix76/2zKry+3VJTs2qTJE7Z/Mhh62+y0xbQ5XKY/ sV05DSdBrOmmeBaJa3gaQkBGMjNYbac0EuP19x4IEa8UvxHuB1ByHXkK+XFN+ogU+m7W 0gKQ== 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=AOguE++p6bD2DCkFUbEQln+n7q5wuFsJXcFCOHE1wDo=; b=b/zASZq3AKn/NKU+Il7jfdIkchohiLGeEJjaE6Iez8FzTEuPX4yr7cr1zvrlxUTWqc kgulbgu04Uad2WM2bjQFXQP6QvALMRc1qbWHUUVmAujOr4vtYZhGBoaiZfLOSVJwPBzf NsEWg8zDmOCgMiqT6hk4zcUK45KQPQyK8xBe72Sid+1bfwzLuDWhOad7XZ9wmjBm1U1l MRKhMqOUOwmpst8tkiddk/KS7VT0a8IYfkXM1moRFmDdmzYAY73F9ZBBOj5VKhx1qfZw u0ro5s8nMC5bYWwX03ScCxRDVZYpGAXaVEF4iQN5X9EnIZ1pD8kF+TnTpPXJLUytiWY/ 5/Pw== 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=AOguE++p6bD2DCkFUbEQln+n7q5wuFsJXcFCOHE1wDo=; b=UOPMm/E+8M+Q9NADyCBHFg55fvvhzJAFWUoJWJRAkJD26I/iB2uEd2lwjXp7/4M9LO HcSaYO9rtQPe3RYroQLwCww7x8IWUdO7l2n9AUJ8q9oXiL0bOYBhicQp3Wv2QuVaSa4q zPe8SlQcJQhDaRh/CBpyDroIKKcMOXIhSYOu13/xxXAfIWg+26TR1Y7Pcn3BdopErzQ+ Sjar29b/3S1uJjAN+VHGAUKNrUX8ccY/kVkAOgGCYhHZbX/qiniuSquVKPn+tVHLiRAI a4I1EIgyiVw1KmXf4UAwM4ExD6kl1o7WhNOMg8tSPm0/e1NtInFYJWc3d/3q485h6PAq U6uA== X-Gm-Message-State: AKwxytdfTNLTMJTHc7EYRyv/iV11u6jweSfsdXokE4DM46EaxDh3QTVu Wdej/OL+2kN/QXHQ3zXkUx3tPw== X-Google-Smtp-Source: ACJfBouZTWuA30YKdBwsupqS05l/dly2ce+yWpRGQMAJMMLqja03WRM6hWEw/mOlxkJF0wCzl9iUvw== X-Received: by 10.176.28.18 with SMTP id a18mr11144082uaj.12.1515947684588; Sun, 14 Jan 2018 08:34:44 -0800 (PST) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.176.33.78 with SMTP id t14ls1829967ual.1.gmail; Sun, 14 Jan 2018 08:34:43 -0800 (PST) X-Received: by 10.31.162.200 with SMTP id l191mr3481072vke.14.1515947682675; Sun, 14 Jan 2018 08:34:42 -0800 (PST) In-Reply-To: <4270ffec-ccc7-4abd-836d-213db296be84@isocpp.org> 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:36623 Archived-At: ------=_Part_2705_599375530.1515947682020 Content-Type: multipart/alternative; boundary="----=_Part_2706_1189767133.1515947682021" ------=_Part_2706_1189767133.1515947682021 Content-Type: text/plain; charset="UTF-8" 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. > 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. (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/08cecc11-e902-4542-a827-53dc45a125d5%40isocpp.org. ------=_Part_2706_1189767133.1515947682021 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Sunday, January 14, 2018 at 6:03:45 PM UTC+2, N= icol Bolas wrote:
...

Static analysis is for looking at wha= t is valid language and deciding whether or not it's likely that the be= havior 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?=C2=A0
Only difference,= the standard should say the implementation should warn the user if this an= d that.
=C2=A0
=
If you make a change to the language, you aren't= "usin= g static analysis"; you've made something linguistically= impossible.

It's like the difference betw= een 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 st= atic analysis easier, that's more a useful additional thing that contra= cts do.

I have a question - is this something the committee is looki= ng 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 believe bringing more (any?) static analysis into the l= anguage is away to keep it modern and relevant, especially, considering C++= very static language and has a lot of compile-time information the tools c= an work with.

Any answers and thoughts are = welcome.

Now on a concrete idea - to use static analysis to make *_view cl= asses safe(er).

This is the wrong tool for the job. The ideal solution is to make su= ch code ill formed, not to rely on "static analysis" to ma= ke compilers give a warning or something.

Or bette= r yet, to change the language to make such code functional. After al= l, 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?

<= code>
A_view(extend A&& arg) : _a(&arg) = {}

...

A_view ref(A{}); //A{}'s lifetime is exten= ded 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).= =C2=A0
But more impartially, what do you rally need it?
Do you really need the lifetime extended, when one could just decl A befo= re view? We are worried about errors and shots in the food, I doubt we need= the extra functionality, considering the complexity.=C2=A0

<= /div>
(I might be wrong, I also considered [[extends_lifetime]] but dis= carded 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/08cecc11-e902-4542-a827-53dc45a125d5= %40isocpp.org.
------=_Part_2706_1189767133.1515947682021-- ------=_Part_2705_599375530.1515947682020-- .