220 36641 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: Mon, 15 Jan 2018 12:07:55 -0800 (PST) Lines: 438 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_2822_1777080784.1516046875619" X-Trace: blaine.gmane.org 1516046759 5960 195.159.176.226 (15 Jan 2018 20:05:59 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Mon, 15 Jan 2018 20:05:59 +0000 (UTC) Cc: mihailnajdenov@gmail.com To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBCUJ3A7GRAPRBHEU6TJAKGQE2GJHCRY@isocpp.org Mon Jan 15 21:05:55 2018 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-vk0-f70.google.com ([209.85.213.70]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ebB10-0001Bi-C7 for gclcip-std-proposals@m.gmane.org; Mon, 15 Jan 2018 21:05:54 +0100 Original-Received: by mail-vk0-f70.google.com with SMTP id o70sf7932220vke.0 for ; Mon, 15 Jan 2018 12:07:58 -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=+0uWhznaFCObt3+XjxO4Ulkl8hfdN8zG292VMz5mu7Y=; b=i8GkZuxR4/x44CKhHSRGEKp3seDfB0b57pAbfSyk1EKGWPWC5i+xFBYpJXT227xZxr vuzRFEGoRKFHwHBn5C3rJPI5eH3liYfCfOjEFSH7UId6WP4Cw6WPZQN7OwtVHZOzlm8t uIpuKCyf0IscFnSpYQUNh9LUJ5H71sDD4/uXeuUeWijoEAuN3psABIkLo8ONjj4IJo7+ nFiyM7D6cLSJTJe9cfn5tJY4lLqurISi2nwhPU7FaP1ZUQaMjnQkgZCWvgHoht9V7vDn EhZqKxf7bqAjQxcyugTKLxyCOIME+0h0kadNzZKs+B4aDaNd/ndXd6zl8XsJO50DlX2M jKrQ== 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=+0uWhznaFCObt3+XjxO4Ulkl8hfdN8zG292VMz5mu7Y=; b=pDXt4LSRt3GWb1V6WqdNStQmhZSmJSLUBVjMrULnqaQzCALnKl/82+gleECY0klHng Fcg9gy0gOTo935VgPuzhzIRXYG6czPnYxRSXRuRYY1ZXhJb16RYv3OXLUIcP1YsCnJqK sZRhCrZYfYx8SlD8bxbonP4elAubRo4fKRRNzBJNJXUEGUP+uxsLYwTipLZfq2QkZPIt qXmapSY4eND3q9O/+F3a9aYuyKGexe7C9VE+K7dRVVjsWUT8suEgyt9WJCsi0uzv1hz9 6iHrdMeA8f58hliNv+dKoXx7RzyEJMDWekU3q5Oo/mwMlxzQmZcjYiGjvUR1wHnt9Ohq 106g== 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=+0uWhznaFCObt3+XjxO4Ulkl8hfdN8zG292VMz5mu7Y=; b=s/1ZE7pcZI0R9YzylYvkVuHZQT5RrUC4G+ll7gAU12piVsE7x+nTTnBty7JPt47eaZ NnutUMUIbGElKvZ99TaAOXK3rnk5kZoKTjX2tKxbjj2uijn8OCYp8F7IUUZEQrEOngMV pIhuHDwS328Xf7Fzm5V3/F3M5tzevcHKB2vvBhblTB8IhAWH1f3ORCqPO01pJ7FACWHs jHXrXB6RSnUdOpVYRE2hRhAcHSnAY9LEmih64Pwn2jjAxeJvk18Vi4MQCbe2D7Ffa+lE m/ATLAWWway0MxlI+GhsQ9DIuXzIW38rfqcEGXZNdgklbdUpKtLi6JAP+MJDFa5Vp8Nm Mzuw== X-Gm-Message-State: AKwxytfifS/PRt/59GD4LHNcWFUVBQ+IHT8dOIiABHp8RbmIMiUquYWK lz1meCMUFXDG5E9m8nVIKZIT3g== X-Google-Smtp-Source: ACJfBotDg+QZJDTZz8HesMBiBiHvcSvdYPoK7TzSMSaBJ5FzCHfC2DY9X6KCQU6moUGsmVLKtmFYvA== X-Received: by 10.31.158.86 with SMTP id h83mr16492086vke.17.1516046878022; Mon, 15 Jan 2018 12:07:58 -0800 (PST) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.31.160.79 with SMTP id j76ls417043vke.17.gmail; Mon, 15 Jan 2018 12:07:56 -0800 (PST) X-Received: by 10.31.161.69 with SMTP id k66mr3871762vke.10.1516046876116; Mon, 15 Jan 2018 12:07:56 -0800 (PST) In-Reply-To: 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:36641 Archived-At: ------=_Part_2822_1777080784.1516046875619 Content-Type: multipart/alternative; boundary="----=_Part_2823_989935661.1516046875620" ------=_Part_2823_989935661.1516046875620 Content-Type: text/plain; charset="UTF-8" On Monday, January 15, 2018 at 7:48:04 PM UTC+2, Nicol Bolas wrote: > > On Monday, January 15, 2018 at 4:27:27 AM UTC-5, mihailn...@gmail.com > wrote: >> >> ... >> >> 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! >> ... >> 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. > Oh, I see. However, does it matter? Consider: A a; A_view ref(std::move(a)); Sure, 'a' is not a temporary, but the same rules apply and still the compiler has all the information it needs. In the extend case the x/prvalue might have been important, but now they are not. The only thing that is important is to have visibility over the dtors, to mark the correct variable, and iff ~A is called first, the compiler will check for uses of ref b/w the calls of the two dtors. > > 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. > If you can't put a fence - you put a sigh. If you can't solve the problem you give a warning (as much as you can). And also, warnings teach better then UB! We can teach exactly as before, the same lessons, however we put *some* safety nets - *for all of us. *Everyone makes mistakes - I forget return statements at least few times a year. > > 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. > I don't know. If there is behavior, then there is incorrect behavior (though legal code). I don't see harm of mandating warnings on incorrect behavior, if possible and if it is not possible for the problem to be solved (make the incorrect illegal). But we are treading off topic here, as I didn't suggest a wildcard solution. > > >> 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/c0383e6d-1422-403a-b1a7-43769f6be4f7%40isocpp.org. ------=_Part_2823_989935661.1516046875620 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Monday, January 15, 2018 at 7:48:04 PM UTC+2, N= icol Bolas wrote:
On Monday, January 15, 2018 at 4:27:27 AM UTC-5, mihailn...@gmail.co= m wrote:
...
You are not fair in your example. I was very specific - th= e 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 hi= nt - it is whole different story if its an language extension.
<= /blockquote>

The heap allocation is irrelevant; the prob= lem is indirect initialization of the object. Consider this:

=
te= mplate<typename T, typename ...Args>
auto initialize(Args ...&&args)
{
=C2=A0 return<= span style=3D"color:#000"> T(std::forward<Args>(<= span style=3D"color:#000">args)...);=
}

a= uto var= =3D initialize<A_view>(A{});

Or even simpler:
=

optional<A_view> ovar(in_place, A{});

Any instance where you initialize `A_vi= ew` via forwarding will not properly detect that you're using a tempora= ry, since the forwarding function cannot tell the difference between an xva= lue and a prvalue.

That's ultimately why I con= cluded that annotation-based solutions can't work, that you have to cre= ate a "third reference" that preserves the prvalue-ness of the ar= gument. That is, if you want to correctly deal with lifetime issues, you ne= ed to be able to tell the difference, not between lvalues and rvalues, but = between lvalues, xvalues, and prvalues.

And techni= cally, 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 i= ts lifetime.

However, even for heap allocated views it will b= e possible to give a warning if view is used after A is destroyed, w= here it is practically impossible to extend the lifetime of A!
= =C2=A0...
You have to give me an example, I am not sure I und= erstand 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 sp= ecification of improper use.
=C2=A0
= See above. The compiler cannot just look at the prvalue argument and an att= ribute 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.

Oh, I see. However,= does it matter? Consider:
<= br>
A a;
=
A_view ref(std::move(a));<= /div>

Sure, = 'a' is not a temporary, but the same rules apply and still the comp= iler has all the information it needs.

In the exte= nd case the x/prvalue might have been important, but now they are not.
The only thing that is important is to have visibility over the dtor= s, to mark the correct variable, and=C2=A0iff ~A is called first, the compi= ler will check for uses of ref = b/w the calls of the two dtors.=C2=A0

=C2=A0
=

Temporaries= , prvalues these have semantic value to us, but in the end - it is the comp= iler just rearranging the calls the dtors. All is visible to him - he creat= ed it.

If we, in this predictable for the compile= r world, want a variable marked so we are informed it is used before anothe= r variable from this same predictable world, I am pretty sure the compiler = can do this for us.

The poi= nt is, not want can't be done (the cases which will not be possi= ble), 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 need= ed 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 care= ful with view types and temporaries". We can teach people about lifeti= me issues and so forth. Maybe not enough programmers get this lesson, but t= he 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 t= o do nothing at all. At least then, we'll always be on our toes. Better= that than to become complacent.


If you can't put a fence - you put a sigh.
If = you can't solve the problem you give a warning (as much as you can).
And also, warnings teach better then UB!
We c= an teach exactly as before, the same lessons, however we put some sa= fety nets - for all of us. Everyone makes mistakes - I forget return= statements at least few times a year.

=C2= =A0

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

Actually I will not be surprised if implementations start doi= ng that by themselves (warning in cases thy can verify). The q= uestion 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 c= learly explicitly specified.

Do= es not change the fact the standard not mandating warnings, it is the imple= mentation which must take the initiative - warning for assignment in if sta= tement, warning for no return, for fallthrough, for empty statements, etc e= tc. These save lifes for pros and juniors alike.=C2=A0
=C2=A0
Ironically = all the standard did is a way to turn these warnings off if they do not mat= ch the intend. However, how about the standard turning warnings on (in case= s impl. agree are implementable).

The standard defines behavior. Warnings are not behavior. Thus, it has n= o right to mandate warnings.

I = don't know. If there is behavior, then there is incorrect behavior (tho= ugh legal code). I don't see harm of mandating warnings on incorrect be= havior, if possible and if it is not possible for the problem to be solved = (make the incorrect illegal).
But we are treading off topic here,= as I didn't suggest a wildcard solution.
=C2=A0 =C2=A0
=
=C2=A0
Granted [= [deprecated]] is such an example but, that is way too little, compared to w= hat it is possible.


Sure it is bett= er to make this code illegal, but what if it is not possible or too hard? A= s the saying (in my language) goes - [It is] better [to have a]sparro= w 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/c0383e6d-1422-403a-b1a7-43769f6be4f7= %40isocpp.org.
------=_Part_2823_989935661.1516046875620-- ------=_Part_2822_1777080784.1516046875619-- .