220 28002 article Path: news.gmane.org!.POSTED!not-for-mail From: "D. B." Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Specifier to cause the destructor to be called at last use instead of end of scope Date: Sun, 28 Aug 2016 09:06:11 +0100 Lines: 119 Approved: news@gmane.org Message-ID: References: <16f4f27a-daf4-4eff-8408-73aadc99e0c5@isocpp.org> <52303ad8-6485-49e6-b797-da61d270627e@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=001a1147284e8f7fac053b1d3863 X-Trace: blaine.gmane.org 1472371579 10455 195.159.176.226 (28 Aug 2016 08:06:19 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sun, 28 Aug 2016 08:06:19 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBCWNZ4ECS4GBB5NWRK7AKGQE3PLGVJQ@isocpp.org Sun Aug 28 10:06:14 2016 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-lf0-f70.google.com ([209.85.215.70]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bdv6b-0002B4-Lg for gclcip-std-proposals@m.gmane.org; Sun, 28 Aug 2016 10:06:13 +0200 Original-Received: by mail-lf0-f70.google.com with SMTP id e7sf79039633lfe.0 for ; Sun, 28 Aug 2016 01:06:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isocpp-org.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :x-original-sender:x-original-authentication-results:reply-to :precedence:mailing-list:list-id:x-spam-checked-in-group:list-post :list-help:list-archive:list-subscribe:list-unsubscribe; bh=KcDdzee5KOjp9QBktgatNcxPZp90ox+EORqHvAHhEHk=; b=wslyV0z8x9fZy1Ngr56ksH/zx4NpRzNGVKqeohoyJZhZHqhPbCi2W7DpIfLosCr2i/ K1vcs4kUqLR29dvJ9/TaceKVqBj8e7ut+G2VzgzZk74VSiI/7j8p88R3+YzrqAHiaBP/ xs6wxVTUGchTxC//YN9XGnsQnnfvpzb5PKbIQ2di7FBsUcDqnoVYeZIPAuR3ai9UTHAp E8qNd9Q4R+QkBAv7LvDOL/c9NJmfP2iSuuNcIpvj0v+i4XZIhDCJRSSd5JaT89twmWTw vHtC9trNe23NDyIzri0v0f0kbc5xQi4FozRJkpJnm0PaN4r4EeHLy8naN57qCoy78LAZ tL0w== 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:from:date :message-id:subject:to:x-original-sender :x-original-authentication-results:reply-to:precedence:mailing-list :list-id:x-spam-checked-in-group:list-post:list-help:list-archive :list-subscribe:list-unsubscribe; bh=KcDdzee5KOjp9QBktgatNcxPZp90ox+EORqHvAHhEHk=; b=W/COCSvECuwkDTBWMXdmnIalA5naRJkWGAg4xqs2cvkZvIsboeIrxqziY9/05AIu2/ iTuoSvhiQB7PVE41bgjsPdx8j8ipBZKXoDJBZSraAyEXLHgwL5mN/o2jfDn62zOUQ/77 /ssIXSQ2fi16vhBxE+Zz2czKCaY7TVyRFFIY5X30QQtI69c103dUVr2YTei0o0q7vr8y +w19LMKLc4MOp182PzRg/sGL0/hwWRuXWnWDkaQGxektyAMzrGEg0HXcH3N5jQrlLfw1 ++kvJYGk0QhOe0oY3kYl1iqXGw4W2Gi5LMHtcFONFIfMQ0DMsCfJwVnU9rfoJph3buzd 37xA== X-Gm-Message-State: AE9vXwMz5pDYgIl2+PRUn7ae0xIPzLxgibWy/qimks/4owAeX0vtJlimL52fMaSVEdM3Kg== X-Received: by 10.46.69.10 with SMTP id s10mr1541079lja.1.1472371574586; Sun, 28 Aug 2016 01:06:14 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.28.63.23 with SMTP id m23ls1957708wma.3.gmail; Sun, 28 Aug 2016 01:06:13 -0700 (PDT) X-Received: by 10.28.107.88 with SMTP id g85mr5991202wmc.49.1472371573337; Sun, 28 Aug 2016 01:06:13 -0700 (PDT) Original-Received: from mail-wm0-x230.google.com (mail-wm0-x230.google.com. [2a00:1450:400c:c09::230]) by mx.google.com with ESMTPS id o74si6969454wme.16.2016.08.28.01.06.13 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 28 Aug 2016 01:06:13 -0700 (PDT) Received-SPF: pass (google.com: domain of db0451@gmail.com designates 2a00:1450:400c:c09::230 as permitted sender) client-ip=2a00:1450:400c:c09::230; Original-Received: by mail-wm0-x230.google.com with SMTP id q128so41228414wma.1 for ; Sun, 28 Aug 2016 01:06:13 -0700 (PDT) X-Received: by 10.28.238.154 with SMTP id j26mr5989453wmi.94.1472371572570; Sun, 28 Aug 2016 01:06:12 -0700 (PDT) Original-Received: by 10.28.15.15 with HTTP; Sun, 28 Aug 2016 01:06:11 -0700 (PDT) In-Reply-To: <52303ad8-6485-49e6-b797-da61d270627e@isocpp.org> X-Original-Sender: db0451@gmail.com X-Original-Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com; spf=pass (google.com: domain of db0451@gmail.com designates 2a00:1450:400c:c09::230 as permitted sender) smtp.mailfrom=db0451@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:28002 Archived-At: --001a1147284e8f7fac053b1d3863 Content-Type: text/plain; charset=UTF-8 On Sat, Aug 27, 2016 at 11:48 PM, Nicol Bolas wrote: > > Hmm. At first, I didn't like the idea of it being merely a hint to the > optimizer. When a destructor gets called is an observable side-effect for > any code where we would care to use such a thing. So it should be something > you could rely on. > > After thinking about it for a bit however, making it a hint does solve a > number of issues. > Heh, I thought I was just inferring what you meant, but instead I came up with a new idea. That was unexpectedly useful! The rest of what you said is a good (probably better than I could've written) outline of what I was thinking. So thanks! Although: > That said, I wonder how likely this is, given that by my understanding, >> we're far into GC territory. But as a non-binding hint to the compiler that >> wouldn't affect semantics of well-formed programs, maybe it's not that >> outlandish at all... we have several of those already. >> > > But it would affect the semantics of well-formed programs. See my tuple > example above; if `T t` had been annotated with the attribute, then it > would make use of `tpl` without the use of `t` undefined behavior. That's > part of the promise you make when you use [[eager-destruct]] or whatever we > call it. > > It's no different from [[noreturn]] in that regard; if such a function > ever actually *returns*, you provoke UB. > > Not sure if this was an imprecise choice of words on my part. But what I really meant was precisely what you said: - the new behaviour could not suddenly wreck any *current*, working, compliant programs - since it'd be an opt-in attribute, and - if one deliberately *added* said attribute but also stashed a reference to an object for which it was declared they would not, the program might compile, but it's on the programmer's head if the optimisation process bites them, as doing so would be UB. -- 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/CACGiwhF_PGSqbfROx5tvxDBj0nsTpao3kOKqSGzpsKmTDwTjTQ%40mail.gmail.com. --001a1147284e8f7fac053b1d3863 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On S= at, Aug 27, 2016 at 11:48 PM, Nicol Bolas <jmckesson@gmail.com> wrote:

Hmm. At first, I didn't like the idea of it being= merely a hint to the optimizer. When a destructor gets called is an observ= able side-effect for any code where we would care to use such a thing. So i= t should be something you could rely on.

After thinking about it for= a bit however, making it a hint does solve a number of issues.

Heh, I thought I was just inferring wh= at you meant, but instead I came up with a new idea. That was unexpectedly = useful! The rest of what you said is a good (probably better than I could&#= 39;ve written) outline of what I was thinking. So thanks! Although:

= =C2=A0
=
That said, I wonder how likely this is, given that by my understandin= g, we're far into GC territory. But as a non-binding hint to the compil= er that wouldn't affect semantics of well-formed programs, maybe it'= ;s not that outlandish at all... we have several of those already.

But it would affect the semantics of well-for= med programs. See my tuple example above; if `T t` had been annotated with = the attribute, then it would make use of `tpl` without the use of `t` undef= ined behavior. That's part of the promise you make when you use [[eager= -destruct]] or whatever we call it.

It's no different from [[nor= eturn]] in that regard; if such a function ever actually returns, yo= u provoke UB.

Not sure if this was an imprecise choice of words = on my part. But what I really meant was precisely what you said:
    the new behaviour could not suddenly wreck any current, working, co= mpliant programs - since it'd be an opt-in attribute, and
=
  • if one deliberately added said attribute but also stashed a = reference to an object for which it was declared they would not, the progra= m might compile, but it's on the programmer's head if=C2=A0 the opt= imisation process bites them, as doing so would be UB.


=

--
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 htt= ps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CACGiwhF_PGSqbfRO= x5tvxDBj0nsTpao3kOKqSGzpsKmTDwTjTQ%40mail.gmail.com.
--001a1147284e8f7fac053b1d3863-- .