220 12433 <1e20b479-8056-4b27-961f-5e23e696604d@isocpp.org> article Path: news.gmane.org!not-for-mail From: Matthew Fioravante Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Local variables that overstay their welcome Date: Sat, 23 Aug 2014 07:05:53 -0700 (PDT) Lines: 149 Approved: news@gmane.org Message-ID: <1e20b479-8056-4b27-961f-5e23e696604d@isocpp.org> References: <778b6fbf-3b58-488c-9e51-32a05b95831e@isocpp.org> <5479ebf1-c490-4646-975c-9b99debd2e42@isocpp.org> <6917A51E-AB34-47E1-8115-7821739D6C22@gmail.com> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_100_821576670.1408802753189" X-Trace: ger.gmane.org 1408802771 15604 80.91.229.3 (23 Aug 2014 14:06:11 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 23 Aug 2014 14:06:11 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBDELF54RTIGRBQN74KPQKGQEPOELBLA@isocpp.org Sat Aug 23 16:06:01 2014 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-oa0-f71.google.com ([209.85.219.71]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1XLBx5-0003da-G9 for gclcip-std-proposals@m.gmane.org; Sat, 23 Aug 2014 16:05:55 +0200 Original-Received: by mail-oa0-f71.google.com with SMTP id g18sf70069881oah.10 for ; Sat, 23 Aug 2014 07:05:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to: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=UVj6eaJOeGJAc8hQCllIrrX1nTXaRaoeu+/NJ9MeJzk=; b=IL6O+l7hPttlchtv8no9vBuCTDu+zxlB1SFcCHTtRQ25VOG7ZxDgJgCpEEpRkuPRIa lrEZ+xFCxYckaFrY9SwjE1Le6LxAiTj4QhrfsJHUJnil/OCxWvrMDdyZvoMbTH8teSVS 6QC6lnPaK4CMXM1M60tVT2qxncPyPpNr1romSJeC8OE1QpY7I2Qm9PHCbxPFGwaREOek MIGoIpK3PbQKMRTB5POTsOLtwsMLgf/0ika36618Nw0cEHQRJZmQlKqgrO6nYv/ynvio azzyFw5Kc0AP1VqhdtEJBlJaGewBo/ifpcRJ1tvUrE1G5hVHEnjKCvjPP9P45AGMgBZT ZVlw== 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: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=UVj6eaJOeGJAc8hQCllIrrX1nTXaRaoeu+/NJ9MeJzk=; b=ObYz/0U8lUKArC6VuLY02uKSnzaZQhP+KNBWVzI6jMMyEc5nr+RUuAxx6XR7uBCT21 wfYHezPwL4ZwVoAGj6B4zLjxarbBY68NXA72KsQYfXY+dCLTPbqtkgpAq8AQzKzKzFXC ROy5KFveBd2XFNC2fpDrPL1kATTvdBkswhoJQqs9cvOht05WKXMk5MEXTcH0erdmaRqG abnAhpaZUcrC5LX7qRWFOgZpmEoQD0LzPZ9sI2exyxSzTTBVS3eF7DZCiqJjK19u4OS3 DAKSdkNrBAy3eva/zyEid1QoVr08LHLtbAC+qyzsvUh34SSsdG/q31L98JnMhN5ogY66 20Og== X-Gm-Message-State: ALoCoQms5v8cIkJ0cNdmKXJWgsu92JR7dDLQBIRhu5CY0J1iH0mQRg1zkILAfHfSUCe4t0JdvDbo X-Received: by 10.42.119.82 with SMTP id a18mr10555218icr.19.1408802754301; Sat, 23 Aug 2014 07:05:54 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.140.27.242 with SMTP id 105ls107451qgx.17.gmail; Sat, 23 Aug 2014 07:05:53 -0700 (PDT) X-Received: by 10.140.98.243 with SMTP id o106mr164qge.17.1408802753582; Sat, 23 Aug 2014 07:05:53 -0700 (PDT) In-Reply-To: <6917A51E-AB34-47E1-8115-7821739D6C22@gmail.com> 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:12433 Archived-At: ------=_Part_100_821576670.1408802753189 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Saturday, August 23, 2014 1:58:51 AM UTC-4, David Krauss wrote: > > > On 2014=E2=80=9308=E2=80=9323, at 6:30 AM, Adam Nevraumont >=20 > wrote: > > How about: > > int i; > i=3D3; > i.~int(); > > Calling the destructor explicitly on a value type variable destroys it an= d=20 > removes it from scope. > > Downside: explicit destructors are otherwise dangerous. > > > I=E2=80=99m horrified. > > I don't like this approach either. I think messing with the destruction=20 order of automatic variables is bad news and possible source of bugs. If=20 you want to destroy something early you can create an extra scope with=20 braces. =20 > The move semantics of most types (especially containers and smart=20 > pointers) define ownership be transferred as owned resources are preserve= d=20 > untouched. If you need an observer to a unique_ptr which meanwhile gets= =20 > transferred into a container, simply use > > auto & observer =3D * owner; // Add const if you can. > > Refactoring move into legacy code is nontrivial,=20 > Indeed, and this is exactly what made me think of this issue.=20 =20 > and better static analysis tools would be nice. Perhaps we would all=20 > benefit from a std::unused() function which does nothing except=20 > communicate intent (i.e., let the implementation try to detect and warn o= n=20 > subsequent use). Maybe also std::reuse() to silence any possible=20 > proactive use-after-move diagnosis, or std::move_but_reuse() to prevent= =20 > the diagnostic analysis from starting in the first place. However,=20 > statically detecting use of a variable through aliases is impossible. > > That's pretty much the same as my idea for std::verbotten.=20 =20 > But there=E2=80=99s nothing special about legacy code that requires new c= onstructs=20 > with their own downsides. Maintenance duty is usually when we=E2=80=99re = most=20 > risk-averse. > > --=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_100_821576670.1408802753189 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Saturday, August 23, 2014 1:58:51 AM UTC-4, Dav= id Krauss wrote:

On 2014=E2=80=9308=E2=80=9323, at 6:30 = AM, Adam Nevraumont <a...@theorem.c= a> wrote:

How about:

int i= ;
i=3D3;
i.~int();

Calling the destructor explicitly on a valu= e type variable destroys it and removes it from scope.

Downside: exp= licit destructors are otherwise dangerous.

I= =E2=80=99m horrified.


I don't like this approach either. I think messing with the destructi= on order of automatic variables is bad news and possible source of bugs. If= you want to destroy something early you can create an extra scope with bra= ces.
 
The move semantics of most= types (especially containers and smart pointers) define ownership be trans= ferred as owned resources are preserved untouched. If you need an observer = to a unique_ptr which meanwhile gets tra= nsferred into a container, simply use

auto & observer =3D * owner; // Add const if you can.

Refactoring move = into legacy code is nontrivial,

Indeed, and this is exactly what made me think of this issue. 
=
 
and better static analysis tools would be nice.= Perhaps we would all benefit from a std::unused() function which does nothing except communicate intent (i.e., let the = implementation try to detect and warn on subsequent use). Maybe also std::reuse() to silence any possible proactive= use-after-move diagnosis, or std::move_but_reuse()<= /font> to prevent the diagnostic analysis from starting in the first p= lace. However, statically detecting use of a variable through aliases is im= possible.

That's pretty much th= e same as my idea for std::verbotten. 
 
But there=E2=80=99s nothing special about legacy code that req= uires new constructs with their own downsides. Maintenance duty is usually = when we=E2=80=99re most risk-averse.

--

---
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_100_821576670.1408802753189-- .