220 14177 article Path: news.gmane.org!not-for-mail From: "dgutson ." Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Re: Proposal for a delete expression for local variables Date: Fri, 24 Oct 2014 00:30:53 -0300 Lines: 185 Approved: news@gmane.org Message-ID: References: <670278fe-3efd-406b-a5be-d8223eb71f21@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1414121464 20002 80.91.229.3 (24 Oct 2014 03:31:04 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 24 Oct 2014 03:31:04 +0000 (UTC) Cc: corentin.schreiber@cea.fr To: std-proposals Original-X-From: std-proposals+bncBDE3NBMV6UFBB3UPU6RAKGQEFODC7FI@isocpp.org Fri Oct 24 05:30:56 2014 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-pd0-f199.google.com ([209.85.192.199]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1XhVaa-0000bH-6n for gclcip-std-proposals@m.gmane.org; Fri, 24 Oct 2014 05:30:56 +0200 Original-Received: by mail-pd0-f199.google.com with SMTP id v10sf3920498pde.10 for ; Thu, 23 Oct 2014 20:30:54 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:x-original-sender :x-original-authentication-results:reply-to:precedence:mailing-list :list-id:list-post:list-help:list-archive:list-subscribe :list-unsubscribe:content-type:content-transfer-encoding; bh=xliWYHjWFYyo6kM8y9l2r5J0PNNioRLAhAMtWWrB5cM=; b=SjUnx5j+JbMb1AR1CgDwtFMPQuebIuL8Rnt9w+AYoisR0+g8c2EHuUM3/GL+dCsOqO rmLF6M5tXCj3gl76Rw5O+ja5WztXCoU+q1GPrJnkV/gVJpnBoZX8WR9rFIPp5tBpVXBS csAyypgBmbnzkr2O2djshkKWmw65AEC5yNP2sKcnJolNM3AUiALet4ajIhJgjBaRfsWG y2M+weE6Uin6QtonZzR3hKEfuoPVtsg6e9DjsWmQ7RjZWxREsGM9EzqljWH4omsRN0jd dXHfuPWTnW50VOFXzLh5hvnXsfYT2le+ch7GONOFiPb1meoOSD0y3+PJWrwlMIBz+h1p eWQA== X-Gm-Message-State: ALoCoQnGJpH+N9i1ahANuluy/+nDcpGOL0x/MMBs93RbApv9uEvutb05gM4ZwQyVBQnFWXxPZhjV X-Received: by 10.66.66.40 with SMTP id c8mr6211326pat.44.1414121454786; Thu, 23 Oct 2014 20:30:54 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.107.172.2 with SMTP id v2ls1105445ioe.1.gmail; Thu, 23 Oct 2014 20:30:54 -0700 (PDT) X-Received: by 10.69.26.133 with SMTP id iy5mr1869407pbd.114.1414121453966; Thu, 23 Oct 2014 20:30:53 -0700 (PDT) Original-Received: from mail-pa0-x231.google.com (mail-pa0-x231.google.com. [2607:f8b0:400e:c03::231]) by mx.google.com with ESMTPS id wt1si3076130pab.202.2014.10.23.20.30.53 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 23 Oct 2014 20:30:53 -0700 (PDT) Received-SPF: pass (google.com: domain of danielgutson@gmail.com designates 2607:f8b0:400e:c03::231 as permitted sender) client-ip=2607:f8b0:400e:c03::231; Original-Received: by mail-pa0-f49.google.com with SMTP id hz1so333389pad.8 for ; Thu, 23 Oct 2014 20:30:53 -0700 (PDT) X-Received: by 10.66.242.203 with SMTP id ws11mr1756740pac.69.1414121453750; Thu, 23 Oct 2014 20:30:53 -0700 (PDT) Original-Received: by 10.70.25.3 with HTTP; Thu, 23 Oct 2014 20:30:53 -0700 (PDT) In-Reply-To: X-Original-Sender: danielgutson@gmail.com X-Original-Authentication-Results: mx.google.com; spf=pass (google.com: domain of danielgutson@gmail.com designates 2607:f8b0:400e:c03::231 as permitted sender) smtp.mail=danielgutson@gmail.com; dkim=pass header.i=@gmail.com; dmarc=pass (p=NONE dis=NONE) header.from=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:14177 Archived-At: On Thu, Oct 23, 2014 at 3:20 PM, wrote: >> So what you are proposing is a cosmetic change (except for the special >> case of function arguments, which was pointed out by Roman Perepelitsa, = but >> I doubt it is really useful). >> >> I would say the points to analyze are therefore making sure that: 1) you >> introduce no nasty side effects, 2) it will not make it easier for >> unexperienced programmers to make mistakes, and 3) the new syntax is cle= arer >> enough that it counter balances the increase in language complexity >> (remember that this feature will have to be taught to people at some poi= nts, >> think about Scott Meyer). > > > I don't think that it is only a cosmetic change. > > 2) Inexperienced programmers usually don't know what stack unwinding is. = The > most probably is that they won't use it. > > 3) I think that it would be easier to explain "operator }" with an "opera= tor > unwind". > > { > unsinged a; > unsigned b; > }//unwind b, unwind a; > > { > unsigned a; > throw 0;//unwind a; > unsigned b; > }//if reached, unwind b; > > { > unsigned a; > return 0;//unwind a; > unsigned b; > }//if reached, unwind b; > > > { > unsigned a; > unwind b; > unsigned a; > unwind a; > }//unwind nothing I don't see any need of special operator since this can be achieved with 'optional': http://pastebin.com/Qnba9gv8 > > PF, ncomputers > > Am Donnerstag, 23. Oktober 2014 12:59:48 UTC-5 schrieb corentin....@cea.f= r: >> >> Le mercredi 15 octobre 2014 09:14:42 UTC+2, Michael Bruck a =C3=A9crit : >>> >>> Hello everyone, >>> >>> >>> I am looking for feedback on the outline for a proposal below. I would >>> like to know if there is interest in such a feature and any ideas on >>> improvements. >>> >>> >>> Regards, >>> >>> Michael >> >> >> I am not so fond of the idea, especially because we have been heavily >> trained to understand and use the consequences of "operator }". This cre= ated >> an empirical rule, according to which (if you forbid yourself to "delete= " >> pointers explicitly and respect the RAII principles) all variables are a= live >> and valid until the end of the scope they were declared in. It would mak= e >> code harder to read for me (and, I suppose, a bunch of other people). >> That being said, a similar situation arises with features that are >> actually part of the current C++ standard. I am thinking in particular a= bout >> those people who refuse to use multiple return statements in a function.= The >> argument is that it breaks the empirical rule they imposed to themselves >> that a function has only one end point. It breaks the flow of the progra= m, >> hence they find it less readable (I am not one of those). Same thing wit= h >> people that refuse to use goto, for similar reasons (I am one of those). >> It's a matter of taste really, because 1) the standard is written so tha= t >> using these features has no undesirable side effects, and 2) in fact you= can >> write optimal code without multiple return statements, and you can write >> optimal without goto. Much like you can write optimal code without your >> proposal : >> >> { >> auto reply =3D []() { >> auto conn =3D []() { >> auto blob =3D []() { >> auto file =3D file_open_rlock("data_snippet"); >> return file.fetch_all(); >> }(); >> >> auto c =3D connect_to_peer("192.128.0.1"); >> c.send(blob); >> return c; >> }(); >> >> return conn.fetch_reply(); >> }(); >> >> auto file =3D file_create("output"); >> file.write(reply); >> } >> >> So what you are proposing is a cosmetic change (except for the special >> case of function arguments, which was pointed out by Roman Perepelitsa, = but >> I doubt it is really useful). >> >> I would say the points to analyze are therefore making sure that: 1) you >> introduce no nasty side effects, 2) it will not make it easier for >> unexperienced programmers to make mistakes, and 3) the new syntax is cle= arer >> enough that it counter balances the increase in language complexity >> (remember that this feature will have to be taught to people at some poi= nts, >> think about Scott Meyer). >> >> Although it seems at first sight that the proposal passes point 1) above= , >> it seems to me that this feature would only be used in very peculiar >> situations, and I don't think it would be wise to use it as a general >> programming habit. The problem is that it might get abused of by student= s, >> or people coming from the C world who still have to learn that "operator= }" >> can do most of the job for them. My impression is therefore that it fail= s >> point 2) and 3). > > -- > > --- > 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. > Visit this group at > http://groups.google.com/a/isocpp.org/group/std-proposals/. --=20 Who=E2=80=99s got the sweetest disposition? One guess, that=E2=80=99s who? Who=E2=80=99d never, ever start an argument? Who never shows a bit of temperament? Who's never wrong but always right? Who'd never dream of starting a fight? Who get stuck with all the bad luck? --=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/. .