220 36625 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 12:44:09 -0800 (PST) Lines: 153 Approved: news@gmane.org Message-ID: References: <0087c1a4-0b36-40ca-8d43-5bfaf0af62ca@isocpp.org> <4270ffec-ccc7-4abd-836d-213db296be84@isocpp.org> <08cecc11-e902-4542-a827-53dc45a125d5@isocpp.org> <4e25f92e-bd17-42e4-9a33-68916ae380d6@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_3609_526591110.1515962650016" X-Trace: blaine.gmane.org 1515962533 30192 195.159.176.226 (14 Jan 2018 20:42:13 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sun, 14 Jan 2018 20:42:13 +0000 (UTC) Cc: mihailnajdenov@gmail.com To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBCUJ3A7GRAPRBG4C57JAKGQETJ3OO7Q@isocpp.org Sun Jan 14 21:42:09 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 1eap6X-0007V1-1w for gclcip-std-proposals@m.gmane.org; Sun, 14 Jan 2018 21:42:09 +0100 Original-Received: by mail-vk0-f72.google.com with SMTP id d130sf6614814vkf.6 for ; Sun, 14 Jan 2018 12:44:13 -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=Qymqn+sBkjtCJ8j0C6+9g1mhUSiJAiY3agL1w3VXZtE=; b=JDpNs4exxq1HUlb7ijOeracSBNuUW83yuyGI29N/knqMLv4xNM6U5TKfL2nFeVLUg6 5kl+HAcU3R6VgRP4ohqbz+/bxKW2vdTpNNZ/xm/pXTqvm7vobSQM5DDxvi0zjBZBGHL3 8+v2SZaGTDbKBNlQb3a+g7r5H/XMV3Sn2vyL4TGo74P4OZQzDgtSgcao6792dQ6IsYG6 I3/ss4SQp2tA2J3nS9TOcyN4hALBvzFt1XmLs+eLndhYCrpW10PDNZGWpG3AlGdyCzry i66eOoAVPCT4J+IFiXmiSwsQe2ci2WZRcZykFxm8rodY+JNNtd/OOMM7g3uraB+j1OxI ulZQ== 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=Qymqn+sBkjtCJ8j0C6+9g1mhUSiJAiY3agL1w3VXZtE=; b=W80HyMM5G8PQDKfnA3mWCj/pn7ofpySry+1hyniN8VUHinOr5S3lk1Vko2JmIMWmnj XpAZeEWJwzX6mxvlxwuBOZD9pLa2tRSVIyzXqQseOgLxrBFflO77uQ0LdSIDd2HhHvs1 eucWBAU55SgktHIal3Qe/+TbC67sUGrnIIjxbpKZkeScXPQlo3DAmOj2s5L9b+3duSis xCmxJNaCg8Qp6BCvjKLiGjnpSOVmmdR80Yz+3fft9kkLzK3/KuSXCRSv4qLdcAMcIG2F MSwW7K1iL7w4uWV1kRg+279efwEOJeckXJzE+TQ9ePMTt+6g4MI0vFT1MHggkbSRm1g/ it5w== 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=Qymqn+sBkjtCJ8j0C6+9g1mhUSiJAiY3agL1w3VXZtE=; b=n2sitTu6dcItXgTgFJ1Az/bqECmhQYAW/2XnwbA27Qa2Di421hcfZRmhyUhCQKvq2o NfJl+RevgC/lnBg0Y142wR3zYFNFkt7mVjh0CSBXJT9MFrqt7GvROmYYNCcyLm4XPK6D 9u5SdpuT6celcmGRf/5grJyRqCo6pVWwYrviyYVoLAOJfL1w0IMhWW11LVUKY3X+g+sP grG38+1BUg0rYSGNToVBYh1dKjkPwK8lZdxyxKsdi5KI+/Q+CV7JDXrHjh+6YJK0AYmx aPFruwnjfvne8N/JSOE+aHhHywI1xSP2eanlHwhmvyXTUVRxsFWbkYyb1ToU6yYZzKIf QvnA== X-Gm-Message-State: AKwxytfNhfGiKHMIWE/ilzNYOQy5ZaDDWBftuig+V+8h1hYv8dtpma4Q WSNzAXhZdOq5fl8u99cSke8wvg== X-Google-Smtp-Source: ACJfBoulU/XZGZsc60QmUvRV4Co5Wgq+Q+ongnIxENkig1ddtQMDUzO8hkNdT7R+LmW0E9iTf/8OYA== X-Received: by 10.31.248.135 with SMTP id w129mr5946738vkh.39.1515962652668; Sun, 14 Jan 2018 12:44:12 -0800 (PST) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.176.48.193 with SMTP id c1ls1456275uam.18.gmail; Sun, 14 Jan 2018 12:44:11 -0800 (PST) X-Received: by 10.31.4.9 with SMTP id 9mr3538933vke.7.1515962650528; Sun, 14 Jan 2018 12:44:10 -0800 (PST) In-Reply-To: <4e25f92e-bd17-42e4-9a33-68916ae380d6@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:36625 Archived-At: ------=_Part_3609_526591110.1515962650016 Content-Type: multipart/alternative; boundary="----=_Part_3610_2072346634.1515962650016" ------=_Part_3610_2072346634.1515962650016 Content-Type: text/plain; charset="UTF-8" On Sunday, January 14, 2018 at 9:05:44 PM UTC+2, Nicol Bolas wrote: > > 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: >>> >>> ... >>> ... >>> >> > 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. > Yeah, but things like attributes are not about the language. And that is OK. If there is an attribute which will help you enforce correct code, why not have it? > ... > > 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 don't find the possibility of adding lifetime extensions realistic. I don't mind it, but I really, really doubt it will ever be added. Is there any work on in that direction? Have ever been any work on that? Not that it is without problems - we break our own rules adding that. Yea, const ref already breaks it, but still. Even semantically is not very accurate - a view is 'slave' to the viewed, should not control it. Also, what will happen with heap allocated views? Will they fail to compile and be illegal? But as I said, I will not fight against lifetime extensions, I just don't see them coming. Ever. Where with said attribute we can *considerably* improve the quality of the user code, making the foot gun very loud. Actually I will not be surprised if implementations start doing that by themselves (warning in cases thy can verify). The question is, why the initiative should always come from them? -- 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/c568fb1e-3e63-4471-9b4a-7d1e6313c4df%40isocpp.org. ------=_Part_3610_2072346634.1515962650016 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Sunday, January 14, 2018 at 9:05:44 PM UTC+2, N= icol Bolas wrote:
On Sunday, January 14, 2018 at 11:34:42 AM UTC-5, mihailn...@gmail.c= om wrote:
On Su= nday, January 14, 2018 at 6:03:45 PM UTC+2, Nicol Bolas wrote:
...
...

And it's that &q= uot;difference" that I'm saying shouldn't happen. If you want = a static analyzer to find bugs, that's great. But the standard should n= ot require it, nor should the standard be getting in the way of that proces= s.

The standard should be about the actual l= anguage.

Yeah, but things like = attributes are not about the language. And that is OK. If there is an attri= bute which will help you enforce correct code, why not have it?=C2=A0
=
=C2=A0
...

You're thinking about it backward= s. If people frequently keep writing code like that, then on some level, th= ey want to write it that way. It's natural for them to. So you can eith= er slap them in the face and make them stop, or you can just make it leg= al and make it do what they expect.

Yes, makin= g 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 &= quot;fixing" its problems?

I don't find the possibility of adding lifetime extensions realistic.= =C2=A0 I don't mind it, but I really, really doubt it will ever be adde= d. Is there any work on in that direction? Have ever been any work on that?=

Not that it is without problems - we break our ow= n rules adding that. Yea, const ref already breaks it, but still. Even sema= ntically is not very accurate - a view is 'slave' to the viewed, sh= ould not control it.
Also, what will happen with heap allocated v= iews? Will they fail to compile and be illegal?=C2=A0

<= div>But as I said, I will not fight against lifetime extensions, I just don= 't see them coming. Ever.

Where with said attr= ibute we can considerably improve the quality of the user code, maki= ng the foot gun very loud.
Actually I will not be surprised if i= mplementations start doing that by themselves (warning in cases thy can verify). The question is, why the initiative = should always come from them?

--
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/c568fb1e-3e63-4471-9b4a-7d1e6313c4df= %40isocpp.org.
------=_Part_3610_2072346634.1515962650016-- ------=_Part_3609_526591110.1515962650016-- .