220 41441 article Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: David Collier Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Re: Destructive move, via forwarding and destructuring operations Date: Mon, 11 Feb 2019 15:41:49 +0000 Approved: news@gmane.org Message-ID: References: <7b2204ba-51d0-481e-9974-10029547031c@isocpp.org> <91aa6796-9935-4a02-8021-0e35264811a0@isocpp.org> Reply-To: std-proposals@isocpp.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="0000000000005448c30581a02637" Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="145356"; mail-complaints-to="usenet@blaine.gmane.org" Cc: "ISO C++ Standard - Future Proposals" To: "Arthur O'Dwyer" Original-X-From: std-proposals+bncBCH4BCOOUIFRBSVPQ3RQKGQEW3VAHEQ@isocpp.org Mon Feb 11 16:42:08 2019 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-ot1-f71.google.com ([209.85.210.71]) by blaine.gmane.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.89) (envelope-from ) id 1gtDie-000bYR-Dd for gclcip-std-proposals@m.gmane.org; Mon, 11 Feb 2019 16:42:04 +0100 Original-Received: by mail-ot1-f71.google.com with SMTP id 32sf11467100ots.15 for ; Mon, 11 Feb 2019 07:42:04 -0800 (PST) ARC-Seal: i=2; a=rsa-sha256; t=1549899723; cv=pass; d=google.com; s=arc-20160816; b=JsKTki62z/kbDU/V8S3DXy2U7iCX/yBAHgsc3O8KqmGwsn5XoI269HJc53v5pLBIVb dlESoEoQOEBAn/tDUhfkcLlz+nU7JgY5sKi/9sXTdOR6gZP09fIFk+Th9DyF+M/S/KeU tXwfEDZOMPg63LubaCL3i62bGjvsLmKcUaWfYqjApwiumKkT9Ovn6dKx9QP0fMo1izIa kbn50ojBTvHp9qvAsiK4cNulCXTa5lAivM8KX3eHDF5rGTFoJG2zXvLNtG1+2eAXdthr TAiA5Idk5cquIs9LAaYxGZ7USDBei7yW/tmOHahoVPIhnQ4SkcPJVbfKlGEAl2Pqi5Do Y/sg== 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=ifJNTQQAbt14cczVQdv1i4zUD1l996iHwbuWGnq9/+o=; b=oSOG8aISusgbFWoI9qK2gLtjc1fsZIPkKzLcJa9O6F09+Ui4paSZnI+SUX6uULfFPe dbOecNSqljH+okDkcOmoMvg5D5y2DG9RLtytLsrBC2r8yzPPEj2iXS6uXEaQNrVgfUQ7 7M/ymUAIWRi2L9Lge1pTRtlvpl3ixMF+eRtx2RY3teoU9tm9yxXhc1yHPcBiDUnyAIcX 4G851R7Rv7gp1TKxyJP0sjixg+4mhj4SP4KrsRNKZ+qXCrP50H9FOP2+OV4rVnUSKsu/ XIreTo1SVMn4pqDUP3++rlk/2LWRJytWyc9h7wutfXqlfKD32FZ/nAjmvhIWhemMD1Dc 8ykg== ARC-Authentication-Results: i=2; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=BcjGVilL; 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=ifJNTQQAbt14cczVQdv1i4zUD1l996iHwbuWGnq9/+o=; b=Vdt+4hsfF1PDXqoLo92zw3i/b59U08hSd5Gwt+noMQzQct4GRIQCtbwunvGKjJ/Lod ljhtscch8pq8zSPW9FyxDry+QzCnY0yNYqoOw6CSmnnFtfuEVp0Yhjddg022iyG+X0Mu Kf3qY2C4IRhdB/pqS4uJrF6gZKKj6X92ZjBZjOITJKsdxUWPI7XXKgGz91ORPXDinRog cYsqTbVzuhoHmuYnmx00eZqEf/hrfHQQ9sCAy+yxaLE/ALIZK7hyFwi45XqpC0TQr5RJ nqsUk+DhUypEqTEm7A9hMhd5VXM3dhE6eEbLB4p464qAsvveVmwBeDi8gnwLUDSG0iLe TXTw== 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=ifJNTQQAbt14cczVQdv1i4zUD1l996iHwbuWGnq9/+o=; b=JkMABL8qMTqHBATe20L+B6rGcTlkmndQQdl5ti6f/RUcA2GBMwlYsT3pG4l6Y4aNOi eeauMCMqri+gjKt4R8FZYbMXldTlhvHmg12szFx9iYxAcvQ552j9+fJU5Y6IzPtcz9fY +zF7UcukmtG71e29WcsvvB5CblGOVdJND3gGIjpNXUg6aG1vjQ6UuvyeSGp4erkXlNTI sV2nN3VC43NmD1ioBrbWhRu9TeN7OUIx5bSMRj3YG3x8aB7NvF3Caglp2xFhuFcpeUmt s6sGYDJ1EDGtWzWKE6kXId4gThTQIaBBiK/61oS+C1Vgp77MjA+WodrCGyAp5dfqY/d0 5rgA== X-Gm-Message-State: AHQUAubHS1HwJ7SnImSMEaak8EEDrm3nrW6pmBrjf32MjuZyvjz0CCoF 8IsTF16Y66NYPZ7z5TnWGUJGZA== X-Google-Smtp-Source: AHgI3IaubfnEIKz6R7TY/+90QsIVmNrlpDpvAXY2j6n95omvybqv2ZIQrWhqc6NxP8I3Rr9tRjP8ug== X-Received: by 2002:a9d:7a44:: with SMTP id z4mr4694189otm.36.1549899722770; Mon, 11 Feb 2019 07:42:02 -0800 (PST) X-BeenThere: std-proposals@isocpp.org Original-Received: by 2002:a9d:5619:: with SMTP id e25ls7942932oti.9.gmail; Mon, 11 Feb 2019 07:42:01 -0800 (PST) X-Received: by 2002:a9d:5e8c:: with SMTP id f12mr29880380otl.343.1549899721567; Mon, 11 Feb 2019 07:42:01 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1549899721; cv=none; d=google.com; s=arc-20160816; b=a2IS6/qmRx+1hs5oE9ZjjRxTB0JER+rUeLbi8CmC/o95EW8batb0ofCPEkZ+vYYNm9 XL7dRyYzd4TTZi2VvV7cjzvgxScgzuIMIF11+hFPozlsgzhBYmwLJjIx1Lzzdw6utAZk 8ak/x7zQNWJ+SBi2qMrU9y67nbFsIHApObWogre3ct5w3r/nWCOTy5peQqPG1UMkUB4g Z5MbJh0uO7W6AzEHiPJhW2t27lB6ziZUQ3slgfVBEhLfVhYqMYv96U1PFkApoqE02Bim GJ2hmPbB4P+MpqFOvWTQrhQ7SXdAjIXuZHPA3hwDU0RdZsbH+GHK9Xr2HaSlPwhXYt3I ZJpg== 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=FISUNkhdqhsp10WLY821rKs6lFO1n+tKRn+8r9Vr+u8=; b=D/uDP/ON5lKizoN+8yyhU6nw6qS7quwljfhp/14/DHCN2hSuoFHHSxGdL6S54ukGoo /Y4361+jbFATdYHqKWh5WVFxwGNV3W+RBcK0yCNkNo4TWnZbhLjq0eSrknA/njdNgOVk xuhFkg0+t4WmG1uJtvH/OQ09Q4tg9Yh5hE9sjBe8XWuGKJwN2gfNNMtfE/Xi0y9OyTUA GX0ClL3Tu+L/ccI6fJM9N2iblUtMDmqtpcD905ilPGQiJ22feiN55LpK/TehDzhV15f/ 8sec+2Z6cQvFYZ9Z4iagGWssln4x9M+fonYjIC5k6RS3gPPWJEXufBj14/TiN7zpTkFS jaWQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=BcjGVilL; 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 q26sor7016126ota.132.2019.02.11.07.42.01 for (Google Transport Security); Mon, 11 Feb 2019 07:42:01 -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:a05:6830:1317:: with SMTP id p23mr2697124otq.55.1549899721357; Mon, 11 Feb 2019 07:42:01 -0800 (PST) In-Reply-To: X-Original-Sender: dcrc2cpp@gmail.com X-Original-Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=BcjGVilL; 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-Google-Group-Id: 399137483710 List-Post: , List-Help: , List-Archive: List-Subscribe: , List-Unsubscribe: , Xref: news.gmane.org gmane.comp.lang.c++.isocpp.proposals:41441 Archived-At: --0000000000005448c30581a02637 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thanks again Arthur. Some responses below. For your remaining points, basically I think you're right and I'll try to rewrite those parts accordingly. On Sun, Feb 10, 2019 at 4:41 PM Arthur O'Dwyer wrote: > (3) Have you thought about the possibility of implementing something like > your proposal via opt-in macros =C3=A1 l=C3=A0 Boost.Move? Is that remote= ly > conceivable? > I'd not given this serious thought before, but actually, it seems like it would work to some extent. You could have an owning_reference class template, with a way to initialize it via a macro (I don't see any other way for it to correctly bind to a temporary). I don't think overload resolution could work as intended for owning_reference lvalues, but perhaps that's not a disaster. The main thing you'd lose would be compile-time safety: if you used a variable after it had been moved from you'd get a runtime rather than a compile-time error. And the library might be prone to creating dangling references if used incorrectly. I also don't see any way to do destructuring without resorting to UB. Because of these things, I'm not sure anyone would actually want to *use* such a library, but it might be useful to implement it to demonstrate the idea. > (6) > > - Moveable values are *not polymorphic*. That is, the dynamic type of > the object that a moveable value refers to is always the same as its s= tatic > type. > - It is permitted to have a moveable value whose type is an abstract > class. > > I don't immediately understand how to reconcile these two statements. It > seems like if they were both true, then it would be possible to have a > variable whose dynamic type was an abstract class type, and that should > never happen (except briefly inside constructors and destructors). > These really are variables whose dynamic type is an abstract class type. I think I've missed out an important point here: the only way you can create a moveable value of an abstract class type is by destructuring an object of some derived type. So when you say they exist "briefly inside ... destructors", that basically *is* what's going on here. > (8) Section 4.3, example "g4" is quite interesting. > void BAD(bool cond) { > T~ x; > if (cond) { > use(x); > } else { > use(>>x); > } > } > void GOOD(bool cond) { > T~ x; > if (cond) { > use(x); > goto done; > } > use(>>x); > done: ; > } > Here "BAD" looks like it should have the same effect as "GOOD", but in > fact "BAD" is ill-formed while "GOOD" is well-formed (according to exampl= e > "g4" in the paper). I think this quirk would not be well received. > You could rewrite BAD as void BETTER(bool cond) { if (T~ x; cond) { use(x); } else { use(>>x); } } I do agree that it would be unfortunate if the rules somehow encouraged use of goto. But the behaviour of GOOD is well-defined so I don't really see any reason to disallow it, unless you deliberately want to hobble goto statements. To be honest I'd have expected that the whole idea of an operator which ends the scope of a variable would lead to several over-my-dead-body objections, so I'd happily concede the relatively minor point about gotos if that would make anyone happy :) --=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/CAB55TMqNbL6n9DtOt8E%2Bzw4yh9h96afX3tODWdTLq3MFW= 8LHnA%40mail.gmail.com. --0000000000005448c30581a02637 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks again Arthur. Som= e responses below. For your remaining points, basically I think you're = right and I'll try to rewrite those parts accordingly.

<= div class=3D"gmail_quote">
On Sun, Feb= 10, 2019 at 4:41 PM Arthur O'Dwyer <arthur.j.odwyer@gmail.com> wrote:
(3) Have you thought about the possibility of implementing so= mething like your proposal via opt-in macros =C3=A1 l=C3=A0 Boost.Move? Is = that remotely conceivable?
<= /div>

=
I'd not given this serious thought before, but actually, it = seems like it would work to some extent. You could have an owning_reference= class template, with a way to initialize it via a macro (I don't see a= ny other way for it to correctly bind to a temporary). I don't think ov= erload resolution could work as intended for owning_reference lvalues, but = perhaps that's not a disaster. The main thing you'd lose would be c= ompile-time safety: if you used a variable after it had been moved from you= 'd get a runtime rather than a compile-time error. And the library migh= t be prone to creating dangling references if used incorrectly. I also don&= #39;t see any way to do destructuring without resorting to UB. Because of t= hese things, I'm not sure anyone would actually want to *use* such a li= brary, but it might be useful to implement it to demonstrate the idea.
=C2=A0
(6)
  • Moveable values are=C2=A0not polymorphic. That is, the dynamic type of the object that a move= able value refers to is always the same as its static type.
  • It is p= ermitted to have a moveable value whose type is an abstract class.
I don't immediately understand how to reconcile these two s= tatements. It seems like if they were both true, then it would be possible = to have a variable whose dynamic type was an abstract class type, and that = should never happen (except briefly inside constructors and destructors).

These really are = variables whose dynamic type is an abstract class type. I think I've mi= ssed out an important point here: the only way you can create a moveable va= lue of an abstract class type is by destructuring an object of some derived= type. So when you say they exist "briefly inside ... destructors"= ;, that basically *is* what's going on here.

= =C2=A0
(8) Section 4.3, example "g4&= quot; is quite interesting.
void BAD(bool cond) {
=C2= =A0 =C2=A0 T~ x;
=C2=A0 =C2=A0 if (cond) {
=C2=A0 =C2= =A0 =C2=A0 =C2=A0 use(x);
=C2=A0 =C2=A0 } else {
= =C2=A0 =C2=A0 =C2=A0 =C2=A0 use(>>x);
=C2=A0 =C2=A0 }
}
void GOOD(bool cond) {
=C2=A0 =C2= =A0 T~ x;
=C2=A0 =C2=A0 if (cond) {
=C2=A0 =C2=A0 =C2= =A0 =C2=A0 use(x);
=C2=A0 =C2=A0 =C2=A0 =C2=A0 goto done;
=C2=A0 =C2=A0 }
=C2=A0 =C2=A0 use(>>x);
done: = ;
}
Here "BAD" looks like it should have the = same effect as "GOOD", but in fact "BAD" is ill-formed = while "GOOD" is well-formed (according to example "g4" = in the paper). I think this quirk would not be well received.

=C2=A0You could rewrite= BAD as

void BETTER(bool cond) {
=C2=A0 = =C2=A0 if (T~ x; cond) {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 use(x);
=C2=A0 =C2=A0 } else {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 use(>= >x);
=C2=A0 =C2=A0 }
}

I do= agree that it would be unfortunate if the rules somehow encouraged use of = goto. But the behaviour of GOOD is well-defined so I don't really see a= ny reason to disallow it, unless you deliberately want to hobble goto state= ments. To be honest I'd have expected that the whole idea of an operato= r which ends the scope of a variable would lead to several over-my-dead-bod= y objections, so I'd happily concede the relatively minor point about g= otos if that would make anyone happy :)

--
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 h= ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAB55TMqNbL6n9D= tOt8E%2Bzw4yh9h96afX3tODWdTLq3MFW8LHnA%40mail.gmail.com.
--0000000000005448c30581a02637-- .