220 36638 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: Mon, 15 Jan 2018 09:48:04 -0800 (PST) Lines: 612 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> <9ec7a895-af7b-43d3-b47a-b7c95ed8660b@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_5610_1263075780.1516038484340" X-Trace: blaine.gmane.org 1516038375 5037 195.159.176.226 (15 Jan 2018 17:46:15 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Mon, 15 Jan 2018 17:46:15 +0000 (UTC) Cc: mihailnajdenov@gmail.com To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBCEKFTV6ZUMBBVOS6PJAKGQE6BY56TI@isocpp.org Mon Jan 15 18:46:10 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 1eb8pf-0000Vo-D2 for gclcip-std-proposals@m.gmane.org; Mon, 15 Jan 2018 18:46:03 +0100 Original-Received: by mail-ua0-f200.google.com with SMTP id g47sf5473632uad.14 for ; Mon, 15 Jan 2018 09:48:07 -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=vVjDQyFPDqi/wNe5+OSzRFXty1qbY4WwUqmbqRbZpeU=; b=aVXZ5dexeLYK4hcxwYtRuFsgAfhJwudu0an6upHsi+g2FTH1Ge+n6NiBinJXnYMrM8 B4gJYQPG3tnTZGlO5Mi/W29WrUy7ixOhsZ60wegUc07P5hUu21u5lLe5fW/wzZU2ONyw nnDMgxy0Dxn+phO59Lw0JuQVhvKQmSoaYdgBtzJEDw2QPs+Jpw3Q7J23S/ICZrGiOcRY mIWOEFiYz6t2LcOOvHEKQdZ4WxU/7RWgaJ9898GLmb54Pa20UgvWbzLvw9V7e56k/+eS KMhAQAbgIh2xV/lD3RGe/rjhP5tArjIgyJ29Y/NBUmZO3dnGqtFIz6HpzNSJU4sTB4GD zIVQ== 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=vVjDQyFPDqi/wNe5+OSzRFXty1qbY4WwUqmbqRbZpeU=; b=dEekya2Jp1ndfxFxqHmthSJW6zIcglidAyjhZLQi7FWcibO4r1VXw1ha0MM/I/ysso 3bEp/OSsFyxga1swJjERoQzWn9tijtFblWHPktaLfY6kCOd9DF+ZcVHmkcCHFuFyTO5a +jTQ5XKICkQ4pOq3eUl+U9ZFx3pFClFA1sPln7rYs0INC+hBWyw9dCTd3IPTontkGLb7 mPEaZmm+TQBVZMwXvFUMA4O0C/5WZGgXWkeUZwmOX9u/QTEyS17LXNPifZgbUiroUC4L AsltyLllOVl8eU64uEHeHVBqJM4lFXJxVYbNteZgS2wKeU1cx46NiLyxp/7u0f3CGLaT 7FGQ== 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=vVjDQyFPDqi/wNe5+OSzRFXty1qbY4WwUqmbqRbZpeU=; b=TyYdt9ZP/ex9cVblcWkCJd0zt3kW5lbMxXZ69aDNCY98cJhnmfBsW6C2TMQO31d7YV uTkG1beXSN/xHB5IqVnCoAh9fSPZPT/LpRPC8/hIAQr5Y0YYO4nq+CN6xw8g8uDIrFRv UsCf95HRbGJaFd6i3dnxsc6TuMe3R/eXNm/tSbydX5Ezw+/3Pe7+qG2uHKfPC9ygTUTP cpL3ngTFqABnYH5xeLGu57agibTJoNKRVjtHIxlCmsKo4fY4YgdPSvMK/iJ6Q+7BDUhm RBQ3t6V+o812pnJLegvnxeQISAr6Y5kOjtB7iFj5yxMM1YbxWKYaw9s1UsXcNhbahglg V2Ww== X-Gm-Message-State: AKwxytc6tlVz1/MU6Fz4ClZeJO+gUoSvIZ/qIfBFaBm/PlHbbR9fqSHG 37ooC0S2ggII/I5nfczJxF17DQ== X-Google-Smtp-Source: ACJfBotfR5arlkUsRSmJRcLLcWUk7HMLJOCMit21FtyaQB5/69QxBpb4iuxqI/eVN2+7VCMOEagTGw== X-Received: by 10.176.48.146 with SMTP id h18mr8347027ual.32.1516038486932; Mon, 15 Jan 2018 09:48:06 -0800 (PST) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.31.151.194 with SMTP id z185ls286784vkd.8.gmail; Mon, 15 Jan 2018 09:48:05 -0800 (PST) X-Received: by 10.31.164.82 with SMTP id n79mr3839220vke.12.1516038484981; Mon, 15 Jan 2018 09:48:04 -0800 (PST) In-Reply-To: <9ec7a895-af7b-43d3-b47a-b7c95ed8660b@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:36638 Archived-At: ------=_Part_5610_1263075780.1516038484340 Content-Type: multipart/alternative; boundary="----=_Part_5611_925091296.1516038484341" ------=_Part_5611_925091296.1516038484341 Content-Type: text/plain; charset="UTF-8" On Monday, January 15, 2018 at 4:27:27 AM UTC-5, mihailn...@gmail.com wrote: > > On Monday, January 15, 2018 at 1:54:32 AM UTC+2, Nicol Bolas wrote: >> >> On Sunday, January 14, 2018 at 3:44:10 PM UTC-5, mihailn...@gmail.com >> wrote: >>> >>> 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? >>> >> >> If attributes aren't "about the language", then why are they defined* by >> the language*? And how do you explain P0840? >> >> ... >>>> >>>> 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? >>> >> >> Yes there has . But apparently, EWG didn't >> consider the cost of consistent use of such annotations to be worth the >> fixing of this problem >> >> . >> >> 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. >>> >> >> Except where it doesn't, of course: >> >> auto ptr = make_shared(A{}); >> >> > You are not fair in your example. I was very specific - the attr will be > ignored for heap allocated views (which are not that widely used, if at > all). In any case an attribute can be ignored - it is just a hint - it is > whole different story if its an language extension. > The heap allocation is irrelevant; the problem is indirect initialization of the object. Consider this: template auto initialize(Args ...&&args) { return T(std::forward(args)...); } auto var = initialize(A{}); Or even simpler: optional ovar(in_place, A{}); *Any instance* where you initialize `A_view` via forwarding will not properly detect that you're using a temporary, since the forwarding function cannot tell the difference between an xvalue and a prvalue. That's ultimately why I concluded that annotation-based solutions can't work, that you have to create a "third reference" that preserves the prvalue-ness of the argument. That is, if you want to correctly deal with lifetime issues, you need to be able to tell the difference, not between lvalues and rvalues, but between lvalues, xvalues, and prvalues. And technically, you need a* sixth* value category too. One that represents the difference between `prvalue.member`, which is not technically a prvalue but can extend the temporary's lifetime, and a function call on a prvalue that returns an xvalue subobject of the prvalue, which doesn't extend its lifetime. However, even for heap allocated views it will be *possible* to give a > warning if view is used after A is destroyed, where it is practically > impossible to extend the lifetime of A! > > > >> After a discussion about the "extend me" proposal idea, I investigated >> the issues with an annotation-based approach. I concluded that the only way >> to make it work would be to add the equivalent of a* third* reference >> type (whether you spell it with `&&&` or some keyword or attribute >> associated with a reference parameter, the effect is to have a thing which >> behaves much like a third kind of reference). Which means you'd have to >> make forwarding references work with such a tool... somehow. >> >> Your attribute-based annotation falls into the same trap: once you leave >> the immediate scope of the code creating the prvalue, it stops being a >> prvalue. So unless the immediate scope knows that the parameter is going to >> be used like this, it can't be annotated properly. >> > > You have to give me an example, I am not sure I understand the issue. > > My logic is very, very simple - as long as we have automatic variables > (aka predictable destruction) the compiler knows *everything* needed to > track improper use, given our specification of improper use. > See above. The compiler cannot just look at the prvalue argument and an attribute on the parameter to tell what's going on. `A_view` is not being fed a prvalue; it's being fed an xvalue. And by all rights, that ought to be fine. Temporaries, prvalues these have semantic value to us, but in the end - it > is the compiler just rearranging the calls the dtors. All is visible to him > - he created it. > > If we, in this predictable for the compiler world, want a variable marked > so we are informed it is used before another variable from this same > predictable world, I am pretty sure the compiler can do this for us. > > The point is, not want *can't* be done (the cases which will not be > possible), but what *can* be done. Covering the trivial cases alone is > not only better then nothing, but will actually amount to 95% of the cases > needed to be covered in the first place. > No, half-measures are actually worse than doing nothing. Why? Because right now, we can teach people "be careful with view types and temporaries". We can teach people about lifetime issues and so forth. Maybe not enough programmers get this lesson, but the information is still out there. But if you give people the illusion that the compiler can handle this issue, that they'll get a compile error or whatever if they improperly use views and temporaries, then people will use view types and temporaries with abandon. They won't realize that the compiler can't catch* all* of these kinds of problems. Without the training to avoid this problem, they're more likely to run into it in indirect initialization cases and so forth, because they have faith the compiler will tell them when they're doing it wrong. If you can't solve this problem, better to do nothing at all. At least then, we'll always be on our toes. Better that than to become complacent. Ultimately, I've come to believe that the only reasonable solution is >> something like `extend_me`: something which explicitly extends the lifetime >> of a temporary, which is the responsibility of the writer of the prvalue >> expression to properly use. >> >> 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? >>> >> >> Because the interaction between two rules of the standard makes this >> legal code behave in a way that is unexpected but clearly explicitly >> specified. >> > > Does not change the fact the standard not mandating warnings, it is the > implementation which must take the initiative - warning for assignment in > if statement, warning for no return, for fallthrough, for empty statements, > etc etc. These save lifes for pros and juniors alike. > Ironically all the standard did is a way to turn these warnings off if they > do not match the intend. However, how about the standard turning warnings > on (in cases impl. agree are implementable). > The standard defines behavior. Warnings are not behavior. Thus, it has no right to mandate warnings. > Granted [[deprecated]] is such an example but, that is way too little, > compared to what it is possible. > > > Sure it is better to make this code illegal, but what if it is not > possible or too hard? As the saying (in my language) goes - [*It is] > better [to have a]sparrow in the hand, then an eagle in the sky.* > > -- 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/dc689be1-8ab4-4c06-86d9-4d9d9cc313b4%40isocpp.org. ------=_Part_5611_925091296.1516038484341 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Monday, January 15, 2018 at 4:27:27 AM UTC-5, mihailn..= ..@gmail.com wrote:
On Monday, January 15, 2018 at 1:54:32 AM UTC+2, Nicol Bolas wrote:
On Sunday, January 14= , 2018 at 3:44:10 PM UTC-5, mihailn...@gmail.com wrote:
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, miha= iln...@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 sta= ndard 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 thi= ngs 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?=C2= =A0

If attributes aren't &q= uot;about the language", then why are they defined by the language<= /i>? And how do you explain P0840?

...

You're thinking ab= out 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 extensi= ons realistic.=C2=A0 I don't mind it, but I really, really doubt it wil= l ever be added. Is there any work on in that direction? Have ever been any= work on that?


Not that it is without pro= blems - we break our own rules adding that. Yea, const ref already breaks i= t, but still. Even semantically is not very accurate - a view is 'slave= ' to the viewed, should not control it.
Also, what will happe= n with heap allocated views? Will they fail to compile and be illegal?=C2= =A0

But as I said, I will not fight against lifeti= me 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.
=
=C2=A0
Except where it doesn't, of co= urse:

auto ptr =3D make_shared<A_view>(A{});


You are n= ot fair in your example. I was very specific - the attr will be ignored for= heap allocated views (which are not that widely used, if at all). In any c= ase an attribute can be ignored - it is just a hint - it is whole different= story if its an language extension.

The heap allocation is irrelevant; the problem is indirect initializa= tion of the object. Consider this:

template<t= ypename T<= /span>, typename ...Args>
auto initialize(A= rgs ...&&args)
{
=C2=A0 return T(std::for= ward<Args<= span class=3D"styled-by-prettify" style=3D"color: #660;">>(args)...);
}

auto var =3D initialize<= /span><= A_view>(A{});
=
Or even simpler:

optionalA_vi= ew> ovar(in_place, A{});

=
Any instance where you initialize `A_view` via forwarding will = not properly detect that you're using a temporary, since the forwarding= function cannot tell the difference between an xvalue and a prvalue.
=

That's ultimately why I concluded that annotation-b= ased solutions can't work, that you have to create a "third refere= nce" that preserves the prvalue-ness of the argument. That is, if you = want to correctly deal with lifetime issues, you need to be able to tell th= e difference, not between lvalues and rvalues, but between lvalues, xvalues= , and prvalues.

And technically, you need a six= th value category too. One that represents the difference between `prva= lue.member`, which is not technically a prvalue but can extend the temporar= y's lifetime, and a function call on a prvalue that returns an xvalue s= ubobject of the prvalue, which doesn't extend its lifetime.
<= i>
However, even for heap allocated views it will be possible t= o give a warning if view is used after A is destroyed, where it is practica= lly impossible to extend the lifetime of A!
=C2=A0
=C2= =A0
Afte= r a discussion about the "extend me" proposal idea, I investigate= d the issues with an annotation-based approach. I concluded that the only w= ay to make it work would be to add the equivalent of a third referen= ce type (whether you spell it with `&&&` or some keyword or att= ribute associated with a reference parameter, the effect is to have a thing= which behaves much like a third kind of reference). Which means you'd = have to make forwarding references work with such a tool... somehow.
<= div>
Your attribute-based annotation falls into the same trap= : once you leave the immediate scope of the code creating the prvalue, it s= tops being a prvalue. So unless the immediate scope knows that the paramete= r is going to be used like this, it can't be annotated properly.
<= /div>

You have to give me an example, I am = not sure I understand the issue.

My logic is very= , very simple - as long as we have automatic variables (aka predictable des= truction) the compiler knows everything needed to track improper use= , given our specification of improper use.
=C2= =A0
See above. The compiler cannot just look at the prvalue argum= ent and an attribute on the parameter to tell what's going on. `A_view`= is not being fed a prvalue; it's being fed an xvalue. And by all right= s, that ought to be fine.

Temporaries, prvalues these have sema= ntic value to us, but in the end - it is the compiler just rearranging the = calls the dtors. All is visible to him - he created it.

If we, in this predictable for the compiler world, want a variable m= arked so we are informed it is used before another variable from this same = predictable world, I am pretty sure the compiler can do this for us.
<= div>
The point is, not want can'= ;t be done (the cases which will not be possible), but what can = be done. Covering the trivial cases alone is not only better then nothing, = but will actually amount to 95% of the cases needed to be covered in the fi= rst place.

No, half-measures are act= ually worse than doing nothing. Why?

Because right now, we can teach p= eople "be careful with view types and temporaries". We can teach = people about lifetime issues and so forth. Maybe not enough programmers get= this lesson, but the information is still out there.

But if you give= people the illusion that the compiler can handle this issue, that they'= ;ll get a compile error or whatever if they improperly use views and tempor= aries, then people will use view types and temporaries with abandon. They w= on't realize that the compiler can't catch all of these kind= s of problems. Without the training to avoid this problem, they're more= likely to run into it in indirect initialization cases and so forth, becau= se they have faith the compiler will tell them when they're doing it wr= ong.

If you can't solve this problem, better to do nothing at all.= At least then, we'll always be on our toes. Better that than to become= complacent.

Ultimately, I've come to believe that the only reasonable= solution is something like `extend_me`: something which explicitly extends= the lifetime of a temporary, which is the responsibility of the writer of = the prvalue expression to properly use.

Actually I will not be surpr= ised if implementations start doing that by themselves (warnin= g in cases thy can verify). The question is, why the initiative should alwa= ys come from them?

Because the = interaction between two rules of the standard makes this legal code behave = in a way that is unexpected but clearly explicitly specified.

Does not change the fact the standard not ma= ndating warnings, it is the implementation which must take the initiative -= warning for assignment in if statement, warning for no return, for fallthr= ough, for empty statements, etc etc. These save lifes for pros and juniors = alike.=C2=A0
=C2=A0
Ironically all the stand= ard did is a way to turn these warnings off if they do not match the intend= .. However, how about the standard turning warnings on (in cases impl. agree= are implementable).

The standa= rd defines behavior. Warnings are not behavior. Thus, it has no right to ma= ndate warnings.
=C2=A0
Granted [[deprecated]] is such an example but= , that is way too little, compared to what it is possible.


Sure it is better to make this code illegal, but wh= at if it is not possible or too hard? As the saying (in my language) goes -= [It is] better [to have a]sparrow in the hand, then an eagle in the = sky.

--
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/dc689be1-8ab4-4c06-86d9-4d9d9cc313b4= %40isocpp.org.
------=_Part_5611_925091296.1516038484341-- ------=_Part_5610_1263075780.1516038484340-- .