220 41373 article Path: news.gmane.org!.POSTED.ciao.gmane.org!not-for-mail From: David Collier Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Destructive move, via forwarding and destructuring operations Date: Mon, 21 Jan 2019 17:01:01 +0000 Approved: news@gmane.org Message-ID: References: <7b2204ba-51d0-481e-9974-10029547031c@isocpp.org> <6b278695-fca9-4bf1-8751-abafc7b0e0dd@isocpp.org> Reply-To: std-proposals@isocpp.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="000000000000d968c2057ffacef3" Injection-Info: ciao.gmane.org; posting-host="ciao.gmane.org:195.159.176.228"; logging-data="223799"; mail-complaints-to="usenet@ciao.gmane.org" Cc: "ISO C++ Standard - Future Proposals" To: =?UTF-8?Q?Thomas_K=C3=B6ppe?= Original-X-From: std-proposals+bncBCH4BCOOUIFRBWXVS7RAKGQEQA4DLAY@isocpp.org Mon Jan 21 18:01:17 2019 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-lj1-f197.google.com ([209.85.208.197]) by ciao.gmane.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.89) (envelope-from ) id 1glcwm-000w98-Aj for gclcip-std-proposals@m.gmane.org; Mon, 21 Jan 2019 18:01:16 +0100 Original-Received: by mail-lj1-f197.google.com with SMTP id 2-v6sf5258917ljs.15 for ; Mon, 21 Jan 2019 09:01:16 -0800 (PST) ARC-Seal: i=2; a=rsa-sha256; t=1548090075; cv=pass; d=google.com; s=arc-20160816; b=gSYl+k52okEE+38mcI7cuLhhxUoyF3V7xaW7z/Ym3+Le0ZugpbdHv7e4QTo6JPs9se 0FSMHyPEUCDX8fsrdWPOSPQl9TmIu5WOH0AM0fgJtR6uBlT05IHaHRlrAr3/hKJ42Ubd DNr5gJ1KrhKxM5Yzy5BL2Pyl5tuPwavR22IgNexmlTNcSDF7B2tUSZj2eQVbodoy9jqS PBLkV5BxQPVRm0jeZDOIoC2ArYSl3thvt2NXCKCn3lg2HyKtdTFF2/1cpovr6WNKz4hH QqQ+WRbEdarsonp6oWzRLddLke9REUONXXWSXNXjMB5cXxGSby2lsOBCjzjy8Q05p3JB 4qww== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:reply-to:cc:to:subject:message-id :date:from:in-reply-to:references:mime-version:dkim-signature; bh=n8fksFCLPu8W8vBfceqeq4vheStzTkxCgLT7m2paIDg=; b=JExSUfSoPu273oCfze0SMGJO6D9DmuEFYVS5+ZCFfRJNqO4XUcBw7s8FtEplscbpLX xzYGEPA1adJmcG1kS4Z7ibbHejuJM0yJ5+W8fBu+xDJnlWXTcf4L43nvTyECJNRg3yr8 GZ8Z7+/WFdf6eSPm3/joxD17K3jmLDAv/0hslTrDdyN2q/FPck50Y+gRtCrD+1zc4afe adX6YpsMlp0Pgb/KOOxmRMI6G+KEx1tpK5hW2qor2NZsJEcT9T94boziwCaVDIxWVGdd 9vDHobgig/5fyBdd8CJXiPwJhuU+81icWlCAsFTskFTdmymPgOZzYFhhRkxG2Qrk/KHS iT6w== ARC-Authentication-Results: i=2; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=G5t4AmNU; spf=pass (google.com: domain of dcrc2cpp@gmail.com designates 209.85.220.41 as permitted sender) smtp.mailfrom=dcrc2cpp@gmail.com; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isocpp-org.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject: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; bh=n8fksFCLPu8W8vBfceqeq4vheStzTkxCgLT7m2paIDg=; b=Qd+VpaglqCjccAgdtd3Crb0VLd0N3qcGdFrMPr/vLzqEwKo4k+KEboC3W1pHdfuZSq GObHHG3yc8fR9ubWx2+uIav+cXScDi5KmDEg2QdhmDYlWuEcLuskEmVTKoqdh/XSErLT kEFOdNe62gnMmJpnlIqeRfaxXa1XJXBZrd0b/+RJDdAMmTa2nVpIA5KAghyaUhe8mzh9 VGgAAXgs6ucrHEr/xDccue6PoG+3uA94OtHMp2Zku9uwIiCpdO4zVr/+vipc1UPtZ+cN OwcGF402QEoDYlV2Py3KDHmvwpFE1tmpQySb7CemkXoUgcPq0ddDoktYoz/EhvcCmSXL E/ug== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc: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=n8fksFCLPu8W8vBfceqeq4vheStzTkxCgLT7m2paIDg=; b=tJwXYBAKku9f+S6On1ODjRBGy9fUUVT+8pC+RlNIkBBPH1lOa6Lo6pE2S93I9upmRT EpVBl/uWlPSffbxVX3PZ7ysBBtkf/lbXV0Y5HXAwRNBKK5TqDam2e8NblPsR4hoFP3r7 afV0dILM9hPhWVMFZb71QG9J70iT7sW+luV5rBZiKCLJdsBsFKLi5lXhGGhk8ECj5cGR aOwj326il4eYdnFoqv1kqFMb/Sv1bRZPerk5G0VTGKVfc9h87HenmrE0IzBc9tlMDldF w95sVnH3H8sdU3W0RqMgA190gb/QsnjXYxe2bh4tJMDIZzlEK6zKZoeE6aMVJybqXwrK YHlw== X-Gm-Message-State: AJcUukfUIvcxC59SrsZ2NbcwyWgmCoHoc9HYc3k+xhQVzhdBTSZGY14g VgX68+OzfNbuaLaqhk+oCWad/A== X-Google-Smtp-Source: ALg8bN6v+LiTghfeD4xDSeOtYFqSVZxCT0+Gyeva/iPQhbi093g+LoWANIbatEebqhBUSNw4LUAg7A== X-Received: by 2002:a19:fc11:: with SMTP id a17mr2054046lfi.11.1548090075580; Mon, 21 Jan 2019 09:01:15 -0800 (PST) X-BeenThere: std-proposals@isocpp.org Original-Received: by 2002:a2e:814b:: with SMTP id t11-v6ls1162086ljg.6.gmail; Mon, 21 Jan 2019 09:01:13 -0800 (PST) X-Received: by 2002:a2e:80d3:: with SMTP id r19-v6mr18085423ljg.151.1548090072810; Mon, 21 Jan 2019 09:01:12 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1548090072; cv=none; d=google.com; s=arc-20160816; b=Zlmnc30owM9VXzC0zp7MJ2EfEtS6qGc40Q/gWdkDkComiIyNEZ7QgFOhp6SIAkWUHi XU09cdYBq8urxJBiajAKuN80Mpil70/4LNkGnh0Tn37qeAX6z+RsAL7I15A5dS6L1hfn h1MNFuTuH2TNU6vlRxhr1rUu+3JykQPbY7jUFXHweP/4ySrxLzjguzrIQethxrERrPym 7XlQC8MsIKfcv4Gn6eo4IAeWQM1J+guQzG7s1zAcD2WzXJW/+3z9i2Z1BcvSLp3Yl5Be 8cNPeiTk0lbDKf8WWqJT3CtxyHFXfIUsisqrS70HMsciZT1dNKZO5t2cJkARQJmoBJsX 7CSQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:dkim-signature; bh=DwdYyOvWZBp8JYPaJBIMUi4MVsVlQYQPB/nLo87EW1A=; b=N3EhQlutPpBhYYbg9lE1VgRMvHb9CpjlY+TMM/y27/NLnCXTQHU5VejK6+UJewsXhg ds5sN/F1fpwr36siR1x36gECWt761gazLnd1qF5R171tcwQ2FyeAIweA2UvpDgTtQokS geHzb/qyCdk66b5t2AsKPaGeFSEctfW6MrGpk3Z94sIrdq4jFRzPJkdrmRwxOpWUtzJv D4pyrf8KLS7Jr7wVFPzTT3NE0oUgtELeeqsMxoKJjbGsJ7DX1wuqshM0ehlzv39hjPxw qcMIrNIp8ZL6XJ+109mksn5EiY/QKRb9vhz6/ZVUytOowwMfpk5s7eQ3/Bl2o6DK5HOz Xzsw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=G5t4AmNU; spf=pass (google.com: domain of dcrc2cpp@gmail.com designates 209.85.220.41 as permitted sender) smtp.mailfrom=dcrc2cpp@gmail.com; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Original-Received: from mail-sor-f41.google.com (mail-sor-f41.google.com. [209.85.220.41]) by mx.google.com with SMTPS id k14-v6sor7580184lji.4.2019.01.21.09.01.12 for (Google Transport Security); Mon, 21 Jan 2019 09:01:12 -0800 (PST) Received-SPF: pass (google.com: domain of dcrc2cpp@gmail.com designates 209.85.220.41 as permitted sender) client-ip=209.85.220.41; X-Received: by 2002:a2e:45d:: with SMTP id 90-v6mr18826117lje.110.1548090072457; Mon, 21 Jan 2019 09:01:12 -0800 (PST) In-Reply-To: <6b278695-fca9-4bf1-8751-abafc7b0e0dd@isocpp.org> X-Original-Sender: dcrc2cpp@gmail.com X-Original-Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=G5t4AmNU; spf=pass (google.com: domain of dcrc2cpp@gmail.com designates 209.85.220.41 as permitted sender) smtp.mailfrom=dcrc2cpp@gmail.com; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=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:41373 Archived-At: --000000000000d968c2057ffacef3 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, Jan 21, 2019 at 3:04 PM Thomas K=C3=B6ppe wrot= e: > Thanks a lot for this post! Just in case this may be of interest to you > (or anyone), I was thinking about approaching destructive moves via a new > value category (and reference type) back in 2014 when this was discussed, > and I noticed a few similarities with your idea. I don't believe my > approach will actually be palatable to the committee (it's too much > complexity for a very niche benefit), but I wrote it up a few weeks ago > regardless and I'm attaching a copy here. My approach is more restrictive > than yours and _only_ works (well) with dynamic allocations, which solves > the original motivation (a std::list whose default/move-from state contai= ns > a dynamic allocation). It does _not_ modify how anything with automatic o= r > static storage works. > Thank you - that's really interesting and definitely more similar to my version than anything else I know of. It looks like a big difference between our approaches is that you say "a cast-to-destroyed-value does not destroy anything", whereas in my version, if you cast to an owning reference, the referred-to object will be always destroyed on that line of code in one way or another. I felt this was important for something like your example: T x(static_cast(*p)); If you know that T has a move destructor then this is fine. What happens if T has only a normal move constructor, or only a copy constructor? In my version, the normal move constructor can be found by overload resolution, and it has the correct effect: the source object is destroyed at the end of the full expression, after it has been (non-destructively) moved from. In your version, how would you ensure that the source is properly destroyed when only the normal move constructor is available? Do you require the compiler to generate a move destructor for all types which don't explicitly provide it? Or do you need to know whether T has a move destructor before you decide to so a static_cast? Are you sending your proposal to the WG21 mailing? > Maybe, if no-one points out any serious flaws. I'm a bit hesitant though because, not having submitted a paper before, something this long and complex would be a pretty crazy place to start. It's not meant to be a proposal anyway - it's too complicated to become a part of C++ - but I was hoping it might provide useful context for P1144 and similar. --=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. To view this discussion on the web visit https://groups.google.com/a/isocpp= ..org/d/msgid/std-proposals/CAB55TMr%3DgARuhDnQWWRPi%2BhhA6Nu2oQBsadGMQWQNT7= Z4Vuw8g%40mail.gmail.com. --000000000000d968c2057ffacef3 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Mon, Jan 21, 2019 at 3:04 PM Thomas K= =C3=B6ppe <tkoeppe@google.com&= gt; wrote:
Thanks a lot for this post! Jus= t in case this may be of interest to you (or anyone), I was thinking about = approaching destructive moves via a new value category (and reference type)= back in 2014 when this was discussed, and I noticed a few similarities wit= h your idea. I don't believe my approach will actually be palatable to = the committee (it's too much complexity for a very niche benefit), but = I wrote it up a few weeks ago regardless and I'm attaching a copy here.= My approach is more restrictive than yours and _only_ works (well) with dy= namic allocations, which solves the original motivation (a std::list whose = default/move-from state contains a dynamic allocation). It does _not_ modif= y how anything with automatic or static storage works.

Thank you - that's really interesting and defin= itely more similar to my version than anything else I know of.
It looks like a big difference between our approaches is that = you say "a cast-to-destroyed-value does not destroy = anything",=C2=A0 whereas in my version, if you cast to an ownin= g reference, the referred-to object will be always destroyed on that line o= f code in one way or another. I felt this was important for something like = your example:

T x(static_cast<T~&>(*p));=

If you know that T has a move destructor then thi= s is fine. What happens if T has only a normal move constructor, or only a = copy constructor? In my version, the normal move constructor can be found b= y overload resolution, and it has the correct effect: the source object is = destroyed at the end of the full expression, after it has been (non-destruc= tively) moved from. In your version, how would you ensure that the source i= s properly destroyed when only the normal move constructor is available? Do= you require the compiler to generate a move destructor for all types which= don't explicitly provide it? Or do you need to know whether T has a mo= ve destructor before you decide to so a static_cast<T~&>?

Are you sending your proposal to the WG21 mailing?

Maybe, if no-one points out any serious flaws= .. I'm a bit hesitant though because, not having submitted a paper befor= e, something this long and complex would be a pretty crazy place to start. = It's not meant to be a proposal anyway - it's too complicated to be= come a part of C++ - but I was hoping it might provide useful context for P= 1144 and similar.

--
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/CAB55TMr%3DgA= RuhDnQWWRPi%2BhhA6Nu2oQBsadGMQWQNT7Z4Vuw8g%40mail.gmail.com.
--000000000000d968c2057ffacef3-- .