220 12379 article Path: news.gmane.org!not-for-mail From: Matthew Fioravante Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Re: Local variables that overstay their welcome Date: Wed, 20 Aug 2014 08:12:13 -0700 (PDT) Lines: 138 Approved: news@gmane.org Message-ID: References: <778b6fbf-3b58-488c-9e51-32a05b95831e@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_4283_1611796945.1408547534043" X-Trace: ger.gmane.org 1408547549 2778 80.91.229.3 (20 Aug 2014 15:12:29 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 20 Aug 2014 15:12:29 +0000 (UTC) Cc: dibeas@ieee.org To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBDELF54RTIGRBTXV2KPQKGQETJKNJBY@isocpp.org Wed Aug 20 17:12:22 2014 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-pd0-f197.google.com ([209.85.192.197]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1XK7Yi-0000E2-M8 for gclcip-std-proposals@m.gmane.org; Wed, 20 Aug 2014 17:12:21 +0200 Original-Received: by mail-pd0-f197.google.com with SMTP id y10sf63806192pdj.8 for ; Wed, 20 Aug 2014 08:12:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; 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:content-type; bh=Bgm3Od45KDwJFLKviWW4K0KgwRw1z8hzjMJVS/0pYBA=; b=FCJaLfgC0OV4OrJR29ysR2n7ipBVVFg3E+EO9sJq+9Idvs3nw935v/pHMgVBLfOIbf GtdA7RxALfQn3BDunTLhQqFoSnpIiEZl4n/F0/TQkmmdoDJjt6V+U86AAKJStkDnRX/s zAR4GAChv0FIRkDJEbnBLcVxmZxR5f+TRJI4Furqzn0lKNbUrHW/4k6fUJ8ND5nztED/ 3OFs10jERj3dEcyQwJley7QKBtEpZsg3JXdrnaXzEyW2RvOhNr4rwEGaO3airU1MyrPV n6EetixNdtwSxtVudWAyvQq7QyoMUjG6s6zfiYujkAUqfG1knCc6INVvNWRbeFP6tEQi df2A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; 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:list-post:list-help:list-archive :list-subscribe:list-unsubscribe:content-type; bh=Bgm3Od45KDwJFLKviWW4K0KgwRw1z8hzjMJVS/0pYBA=; b=VYNLd1ECyiA4WehLsHhCFE+yyAETN/+otkhmpe26sbF/fS3RjdQ9rOaD22YxBmTuxk x4sYVDg2skvZljnm3g2LoyAKHwOOaBOQME+DnGCQZvrQrkazRDV9SAy4czRntm+q4HCE 4SPkXGs+HBdtepGnLYxqEaKnyGRW+lHdjVA50v8lfHcfb0h9Co0FkSLHQZ5TiepZxT+d CApdRD1k8QwvdAodriaWuXRZ8reLKN0t9C2m0m0fmt7VgS4JuBnFz/+zF85DMq2c2WR3 uXbgwhwENB6PqYcktDNawLv7n8SPSFpUQ7uUI2oT+TaDgfz5fsafsQWlvHggT9RJCxVS EOYQ== X-Gm-Message-State: ALoCoQm11pzTbNQ38CB1O60wfuMLhjlTwC0zlb/2Mk1MulY54L9UvPiFS/bWqMiRKmeGreJHktMh X-Received: by 10.66.66.196 with SMTP id h4mr25315701pat.22.1408547535316; Wed, 20 Aug 2014 08:12:15 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.140.40.134 with SMTP id x6ls307081qgx.45.gmail; Wed, 20 Aug 2014 08:12:14 -0700 (PDT) X-Received: by 10.140.95.199 with SMTP id i65mr12526qge.38.1408547534444; Wed, 20 Aug 2014 08:12:14 -0700 (PDT) In-Reply-To: X-Original-Sender: fmatthew5876@gmail.com Precedence: list Mailing-list: list std-proposals@isocpp.org; contact std-proposals+owners@isocpp.org List-ID: 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:12379 Archived-At: ------=_Part_4283_1611796945.1408547534043 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Wednesday, August 20, 2014 11:02:56 AM UTC-4, David Rodr=C3=ADguez Ibeas= =20 wrote: > > There are different things in here...=20 > > For local variables I would expect this to be QoI. The compiler=20 > (specifically if it is doing flow analysis) or a static analysis tool=20 > should be able to pick this up and warn you in this case, while allowing= =20 > other correct reuses of the variable (as in resetting the value to a=20 > different value).=20 > =20 I'm not sure this is actually possible for static analysis tools. There can= =20 be cases where you want use the value after it is moved from. =20 auto x =3D std::make_unique(); if(something) { v.push_back(std::move(x)); } foo(x.get()); //Ok: if something was true then foo gets passed a nullptr,= =20 which is what we want =20 =20 =20 > Still for local variables, while I don't see this as a problem to solve I= =20 > would not be against the solution. > > For non-local variables this is problematic and I would be completely=20 > against it. Say that the member function has a 'kill i' for some member= =20 > variable 'i'. Now you have a nice feature that hides from lookup the memb= er=20 > variable *inside the rest of this function*, but as soon as the function= =20 > completes the user calls on any other function and the variable is seen a= nd=20 > can be used even if from the point of view of the user that member was=20 > *killed*! And in this case, the compiler cannot help, so you are trading= =20 > something that can be detected locally to a different issue that cannot b= e=20 > diagnosed. > =20 I'm not sure using kill to hide data members and/or globals is actually=20 useful. Its certainly not the intention here but just a side effect of how= =20 this proposed kill would work. The main focus is on local variables. =20 =20 Just to clarify in case anyone is confused, the 2 ideas are: =20 kill - All this does is remove the symbol from lookup. std::verboten() - Tags the symbol as verboten, all references of this=20 symbol become compiler errors. --=20 ---=20 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 e= mail to std-proposals+unsubscribe@isocpp.org. To post to this group, send email to std-proposals@isocpp.org. Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa= ls/. ------=_Part_4283_1611796945.1408547534043 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Wednesday, August 20, 2014 11:02:56 AM UTC-4, David= Rodr=C3=ADguez Ibeas wrote:
T= here are different things in here...

For local variables I would ex= pect this to be QoI. The compiler (specifically if it is doing flow analysi= s) or a static analysis tool should be able to pick this up and warn you in= this case, while allowing other correct reuses of the variable (as in rese= tting the value to a different value).
 
=
I'm not sure this is actually possible for static analysis tools. Ther= e can be cases where you want use the value after it is moved from.
 
auto x =3D std::make_unique<int>();
if(= something) {
  v.push_back(std::move(x));
}
foo= (x.get()); //Ok: if something was true then foo gets passed a nullptr, whic= h is what we want
 
 
 
<= blockquote style=3D"margin: 0px 0px 0px 0.8ex; padding-left: 1ex; border-le= ft-color: rgb(204, 204, 204); border-left-width: 1px; border-left-style: so= lid;" class=3D"gmail_quote">
Still for local variables, whi= le I don't see this as a problem to solve I would not be against the soluti= on.

For non-local variables this is problematic and I would be completely a= gainst it. Say that the member function has a 'kill i' for some member vari= able 'i'. Now you have a nice feature that hides from lookup the member var= iable *inside the rest of this function*, but as soon as the function compl= etes the user calls on any other function and the variable is seen and can = be used even if from the point of view of the user that member was *killed*= !  And in this case, the compiler cannot help, so you are trading some= thing that can be detected locally to a different issue that cannot be diag= nosed.
 
I'm not sure using kill = to hide data members and/or globals is actually useful. Its certainly not t= he intention here but just a side effect of how this proposed kill would wo= rk. The main focus is on local variables.
 
 =
Just to clarify in case anyone is confused, the 2 ideas are:
 
kill - All this does is remove the symbol from look= up.
std::verboten() - Tags the symbol as verboten, all references= of this symbol become compiler errors.

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/<= /a>.
------=_Part_4283_1611796945.1408547534043-- .