220 41438 article Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: "Arthur O'Dwyer" Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Re: Destructive move, via forwarding and destructuring operations Date: Sun, 10 Feb 2019 11:42:02 -0500 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="0000000000009bda7b05818cdb07" Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="256606"; mail-complaints-to="usenet@blaine.gmane.org" To: "ISO C++ Standard - Future Proposals" , David Collier Original-X-From: std-proposals+bncBDLZJYWNDQIKDKEB4MCRUBBXN5TFQ@isocpp.org Sun Feb 10 17:41:08 2019 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-wm1-f72.google.com ([209.85.128.72]) by blaine.gmane.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.89) (envelope-from ) id 1gssAF-0014cG-PR for gclcip-std-proposals@m.gmane.org; Sun, 10 Feb 2019 17:41:07 +0100 Original-Received: by mail-wm1-f72.google.com with SMTP id f6sf4571331wmj.5 for ; Sun, 10 Feb 2019 08:41:07 -0800 (PST) ARC-Seal: i=2; a=rsa-sha256; t=1549816867; cv=pass; d=google.com; s=arc-20160816; b=hqLJ/iCrN7Yop1SFIhYzT1xabO+eNAfAO+OVL0/2ugp0rt6C2t9fkNKOk4ooUh8r5T PRMQt91hmIUGBvfGdqHTLM9PYFdIaP75gPAfeaLyJ3RIIiIa5GV8Hp0clRpJ++VfVgrc W009U4sjefanj1+Z47F09NYyfElEAScn3Wn3l55igVlqXD4EIOOoydA+lnY54eoL7xDS 9EzhmrbVY3n2DRKpKn0U/MbBDP/ke3WbSdFSLhUwsTX1ii0A69eJzIKHP9tC4pP5Rb6v ltYDwvDWRjPnQjvzNVJ05LyrAgorZFxw8omy+Ofy2733ulR9l9msvAR/MYQ6u3UckIVD Qjfw== 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:to:subject:message-id:date :from:in-reply-to:references:mime-version:dkim-signature; bh=x+iMKYtv79Sl/e9X7UT5xuDbexs69aJUcBO8T7OgU/E=; b=yBIvxDGthPU3VzQtECNcBAV53IQXxDi/yLnvCtBPRAKBUFsJozvtybGeYB00mUOdZU oal2X5XJhNafsnPNbc2vJcm5j0EnPEvuceImw/c/8cPp6KEdVonvGZkGtm/H//YgKKmM Ulay2jDEqRr+syJSgZn37bFBVH9LwH8QVB7P8aq1wlyRAL9EMmJQ63O/C5OpRisdZx+b 6re5FNN1d/VjWZXT17nuJ+wObFepYxvJM887++FmzTJQ4I1SIrrheaZHWLJwdyMKaKZ/ 740YvpJxIdbbgDWcOh1sd42/qVyP6KZrUcdoAo6Xn1lGz4/elvtm0IuWLvCNt5G3Hb8h 9Jpw== ARC-Authentication-Results: i=2; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=uP8WT71b; spf=pass (google.com: domain of arthur.j.odwyer@gmail.com designates 209.85.220.41 as permitted sender) smtp.mailfrom=arthur.j.odwyer@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 :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=x+iMKYtv79Sl/e9X7UT5xuDbexs69aJUcBO8T7OgU/E=; b=RvbTi5riDdPsw69Gu5l5zcmlepsnxsFimWpVNARKpy3ZCEL68Ik68bhYaYFxH/XZwq iUV1BUKVsE7jw1tINcY3y0CdV9bmc6mKuXxt4n4GtLpZvWZvVdNNcEzaN+dM1QppAmHy n0CEUEJlJQaAl35a5uYX2V15v+ka9C7b7Q6ky2ZkZXFQK32JK9VKm6EiYR5ZidSBDmqL MNd7OH5YOWOichRCShDCL4SnYTkD3t4w+6Tat2pYUJuZ7dnmV0UhJDJhil6B5oYH6ZiO 59PD8wbsICOIBBdJLEaF/CK6w+m6Bjv0WxLQCIcr51Q9+gwjNLCORpd0D9AQuijSJVAP us+Q== 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: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=x+iMKYtv79Sl/e9X7UT5xuDbexs69aJUcBO8T7OgU/E=; b=iK3x7nieEwh9PfWQ6jgaq7jyia5jQ+/dZjlVYSw6nQSzlhZwCFfEN7BSB6l4GnxjtA 6U1Blyn8F1vj3t0Z5mqbtf1BSpf3K1Q+QnbUP0PCJ+OEzoh1cFLAWBh9kAx/ZfkC5b+x GHXD9TvOKp9gEUvlfZ29qfBHGyMnsgTRLFq5g6TawRGO+bAveKCTuQ1fGPATV7Vdaejm sn0HQTvOmRHlKeGrSOlk8if5v+/K0pljwl2B4k980LhDRP7kD7mprZbEKdUjvWh9PA9M nT6I7ZJO5GhPmhCk/I+tJt+kYVE2xq99yp3FY3ekNzblt1qnj4ZqIWExLPog+WbmHP5t VuNg== X-Gm-Message-State: AHQUAuawnUzyA/M3l6JKdQcS0kT2cYLDKDfFu/2I0hPERURH8R2c497/ Vyt9rSguMHlptlxTreAVS4c1fA== X-Google-Smtp-Source: AHgI3IbuKs9H5tGNCKy2nblKn4J914HcXyqHIOazEWsGXpu4fxyf9Iu/p50nnsmsHr3l3weRqMW4vw== X-Received: by 2002:a1c:2dd0:: with SMTP id t199mr425330wmt.21.1549816866853; Sun, 10 Feb 2019 08:41:06 -0800 (PST) X-BeenThere: std-proposals@isocpp.org Original-Received: by 2002:adf:ef4a:: with SMTP id c10ls1364812wrp.5.gmail; Sun, 10 Feb 2019 08:41:04 -0800 (PST) X-Received: by 2002:a5d:5285:: with SMTP id c5mr22899623wrv.167.1549816864489; Sun, 10 Feb 2019 08:41:04 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1549816864; cv=none; d=google.com; s=arc-20160816; b=UBh3MfZgGZGo00KiAFCY5SmPlG8GDDMzkz2t7Gi57DId+kujFEjpPHkx4OLvLTnPCi ApZvnzcXmtYX5ueo4TS6slyxRl+77JojdQocYnT34cCbDtlQAg6AOLLH/HTQ4SKhzXf7 AtAKGmtF4jCigGsTQMY2bP8PTEz6AQ3I7z/u4ZDjfVruCPINjeDfydHQnOhOXsmhQMR/ PmuHNLmfX9t4zoCzYKFgUtvlkAfqGBueTiS55jrVkEGVpg8HTg2eenxdBEoiWCjKaRi1 c0CWHPh8AcFeOLBKHgn9o3ZFPdcJ+0aKN0tOj3zsPyjT2XRkXMJdiIc8EjiZY2QtRWKX nifQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :dkim-signature; bh=p+HiJfrjDtNJh9MkDovaCDgMgkzOOKnbMoy8clWp5+o=; b=QFi8brxhw0CzGFPaDOawRZEknmoRMKtDuiRtKf1zmLOvtYtqllhIOtbMCnECxZ7bR3 9FuYiF+jdeYhAoenBCJKRws8dZYV+vtEjGYcSHTC2UTWYo+1NkJar4mfvmTysA7D2A8j e9+a+bto49Wz2SNBqMP0SC8/e3KP4oqtdypAXAQMPKafHUi45jCOP79/mV/CfpP5m3Cd AVBMEqEww/N6Sv9Vs8N6p565mXO/MMiGDdjnFW4xAy6wKgeis1DCRLMNpCGmmdfub0NC WjkrZdwjtJBiXaMkUMkbmwM7diVX8YZ8o2fPszRBIef5kgl12uSyAICDCpwOcBpehoZ6 EpqQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=uP8WT71b; spf=pass (google.com: domain of arthur.j.odwyer@gmail.com designates 209.85.220.41 as permitted sender) smtp.mailfrom=arthur.j.odwyer@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 q186sor4746503wme.15.2019.02.10.08.41.04 for (Google Transport Security); Sun, 10 Feb 2019 08:41:04 -0800 (PST) Received-SPF: pass (google.com: domain of arthur.j.odwyer@gmail.com designates 209.85.220.41 as permitted sender) client-ip=209.85.220.41; X-Received: by 2002:a1c:f71a:: with SMTP id v26mr5827798wmh.131.1549816863378; Sun, 10 Feb 2019 08:41:03 -0800 (PST) In-Reply-To: <91aa6796-9935-4a02-8021-0e35264811a0@isocpp.org> X-Original-Sender: arthur.j.odwyer@gmail.com X-Original-Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=uP8WT71b; spf=pass (google.com: domain of arthur.j.odwyer@gmail.com designates 209.85.220.41 as permitted sender) smtp.mailfrom=arthur.j.odwyer@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:41438 Archived-At: --0000000000009bda7b05818cdb07 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi David, Here's my laundry list of comments on the current draft. Nothing big here, just a lot of nitpicks. :) (1) Is the README on that repo still an accurate summary of the paper's contents? (2) The README should include a prominent link to a rendered version of the paper, e.g. https://htmlpreview.github.io/?https://github.com/dcrc2cpp/destructive-move= /blob/master/destructivemove.html , for the reviewer's convenience. Don't make me do work in order to read your paper! :) (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 remotely conceivable? (4) - It should be possible to write user-defined destructive move operations. As a particular example, if classes A and B are Relocatable, then it should be possible to write a relocation operation for std::pair= . IMO `pair` is a bit of a poor example, because the relocation operation for `pair` intuitively is nothing more or less than the combination of its sub-objects' relocation operations. So `pair` would be the canonical example of a type that doesn't need a user-defined destructive-move operation, because the "defaulted" destructive-move operation would be adequate. I believe an appropriate example here would be "...if class T is Relocatable, then it should be possible to write a relocation operation for std::optional." The relationship between T and optional preserves *trivial relocatability* in the P1144 sense. But, if T's relocation operation is allowed to have side effects (so that "relocating a present T" and "relocating an absent T" have *different* effects), then the programmer must put an `if` inside optional's destructive-move implementation. (5) for arguments passed by value, implementations are permitted, but not required, to make destruction the responsibility of the callee You might explicitly state that MSVC does do this, but Itanium ABI does not= .. https://quuxplusone.github.io/blog/2018/11/12/parameter-lifetime-and-trivia= l-abi/ (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 sta= tic 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). (7) This would be valid if T has a C++11 move constructor. Or copy constructor, surely? I believe 3.1 is slipping uncontrolledly among the notions of "we disallow X because it would lead to double-destructions," "we disallow X because its natural interpretation would be inefficient =C3=A1 l=C3=A0 vector::push_front," "we allow X but yo= u shouldn't write it because its interpretation is inefficient," and "I didn't even think to consider X because its natural interpretation is inefficient." Section 3.1 pointedly declines to consider the idea of using a *prvalue* (e.g. the result of a function call) to initialize a moveable value, except in the above-quoted case where it's considering and rejecting(?) the idea of using a prvalue of the wrong type. (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 example "g4" in the paper). I think this quirk would not be well received. (9) With this definition: - If an argument is a prvalue expression of type T, then the corresponding template parameter will be deduced as T~, and the function parameter will have type T~. - If an argument is an owning reference T~, then the corresponding template parameter will again be deduced as T~, and the function parameter will have type T~. - If an argument is an lvalue T&, then the corresponding template parameter will be deduced as T&, and the function parameter will have type T&. - If an argument is an rvalue reference T&&, then the corresponding template parameter will be deduced as T&&, and the function parameter will have type T&&. This paragraph incorrectly conflates "value category" with "reference-type-ness." I frequently do so myself, informally, but here I think the conflation is a bad thing. Specifically, the second bullet seems to be implying that T~ t; forward_to_f(t); would deduce parameter `x` as type `T~`, whereas I think really it should be deduced as `T&` because `t` is still an lvalue, even though it is also an owning reference `T~` in terms of decltype. (I mean, `decltype(t)` is `T~`. I assume. This isn't covered explicitly anywhere AFAICT.) (10) Section 7.3: I think you should explain why >>o.class should be preferred over the more obvious >>o.Base. (11) Section 9.2's `remove_range` name and signature don't make any sense to me. Surely the Callback should be passed by plain old value (STL-style) or by const reference (sane style), and it's the *parameter to Callback* (n= ot pictured in the signature) that will be passed by moveable value. Also, this doesn't seem to have anything to do with the STL's "remove" verb. It seems more like an "*erasing* [not *removing*] foreach". (12) Section 9.1 seems to be the most interesting section for somebody looking to implement `std::optional::optional(optional~)`. I wouldn't necessarily say that the current Section 7.5 is *useless*, but I do want to see a version of Section 7.5 that shows how to implement `optional`'s relocating constructor. HTH, Arthur On Sat, Feb 9, 2019 at 2:22 PM wrote: > An updated version of this paper is now at > https://github.com/dcrc2cpp/destructive-move > > The main change is that the role of "owning references" has been > downplayed: owning reference variables have been renamed "moveable values= ", > and they have been made more like non-reference variables. They can be > initialized from an lvalue or rvalue reference, which was previously > disallowed - this now calls the copy constructor or move constructor as > appropriate, just as if a non-reference variable was being initialized. > > Also the behaviour of the forwarding operator has been rephrased in terms > of changes to the scoping rules: the forwarding operator ends the scope o= f > the reference that it applies to. Hopefully this better explains what is > going on: the compiler does not have to track the lifetime of objects - t= he > lifetime of an object is determined by the scope of the variable that > refers to it. > > -- > You received this message because you are subscribed to a topic in the > Google Groups "ISO C++ Standard - Future Proposals" group. > To unsubscribe from this topic, visit > https://groups.google.com/a/isocpp.org/d/topic/std-proposals/zVg_bHmtlcU/= unsubscribe > . > To unsubscribe from this group and all its topics, 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/91aa6796-993= 5-4a02-8021-0e35264811a0%40isocpp.org > > . > --=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/CADvuK0LaM%2BLBuE1OqCMbDbvZBO%3Df%3DDn5z296wYV9r= ScRvdtN_A%40mail.gmail.com. --0000000000009bda7b05818cdb07 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi David,

Here's my laundry list of comments on the current draft. Nothing big h= ere, just a lot of nitpicks. :)


(1)= Is the README on that repo still an accurate summary of the paper's co= ntents?

(2) The README should include a prominent = link to a rendered version of the paper, e.g.=C2=A0https://htmlpreview.github.io/?https://github.com/dcr= c2cpp/destructive-move/blob/master/destructivemove.html , for the revie= wer's convenience. Don't make me do work in order to read your pape= r! :)

(3) Have you thought about the possibility o= f implementing something like your proposal via opt-in macros =C3=A1 l=C3= =A0 Boost.Move? Is that remotely conceivable?

(4)= =C2=A0
    It should be possible to write user-defined destructive move operations. A= s a particular example, if classes=C2=A0A=C2=A0and=C2=A0= B=C2=A0are Relocatable, then it should be possible to write a reloca= tion operation for=C2=A0std::pair<A, B>.
I= MO `pair` is a bit of a poor example, because the relocation operation for = `pair` intuitively is nothing more or less than the combination of its sub-= objects' relocation operations. So `pair` would be the canonical exampl= e of a type that doesn't need a user-defined destructive-move operation= , because the "defaulted" destructive-move operation would be ade= quate.
I believe an appropriate example here would be "...if= class T is Relocatable, then it should be possible to write a relocation o= peration for std::optional<T>." =C2=A0The relationship between T= and optional<T> preserves trivial relocatability in the P1144= sense. But, if T's relocation operation is allowed to have side effect= s (so that "relocating a present T" and "relocating an absen= t T" have different effects), then the programmer must put an `= if` inside optional<T>'s destructive-move implementation.

(5)
for arguments passed by value, implemen= tations are permitted, but not required, to make destruction the responsibi= lity of the callee
You might explicitly state that MSV= C does do this, but Itanium ABI does not.

(6)
  • Moveable values are=C2=A0not pol= ymorphic. That is, the dynamic type of the object that a moveable valu= e refers to is always the same as its static 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 ne= ver happen (except briefly inside constructors and destructors).
=
(7)
This would be valid if=C2=A0T=C2=A0has a C++11 move constructor.

Or copy constructor, surely?=C2=A0 I bel= ieve 3.1 is slipping uncontrolledly among the notions of "we disallow = X because it would lead to double-destructions," "we disallow X b= ecause its natural interpretation would be inefficient =C3=A1 l=C3=A0 vecto= r::push_front," "we allow X but you shouldn't write it becaus= e its interpretation is inefficient," and "I didn't even thin= k to consider X because its natural interpretation is inefficient."
Section 3.1 pointedly declines to consider the idea of using a p= rvalue (e.g. the result of a function call) to initialize a moveable va= lue, except in the above-quoted case where it's considering and rejecti= ng(?) the idea of using a prvalue of the wrong type.

(8) Section 4.3, example "g4" 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);<= /div>
=C2=A0 =C2=A0 }
}
void GOOD(bool= cond) {
=C2=A0 =C2=A0 T~ x;
=C2=A0 =C2=A0 if (cond) {<= /div>
=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" l= ooks like it should have the same effect as "GOOD", but in fact &= quot;BAD" is ill-formed while "GOOD" is well-formed (accordi= ng to example "g4" in the paper). I think this quirk would not be= well received.

(9)
With this definition:
  • If an argument is a prvalue expression of type=C2=A0T, th= en the corresponding template parameter will be deduced as=C2=A0T~, and the function parameter will have type=C2=A0T~.
    • <= li>If an argument is an owning reference=C2=A0T~, then the cor= responding template parameter will again be deduced as=C2=A0T~= , and the function parameter will have type=C2=A0T~.
  • I= f an argument is an lvalue=C2=A0T&, then the corresponding= template parameter will be deduced as=C2=A0T&, and the fu= nction parameter will have type=C2=A0T&.
  • If an arg= ument is an rvalue reference=C2=A0T&&, then the corres= ponding template parameter will be deduced as=C2=A0T&&= , and the function parameter will have type=C2=A0T&&.<= /li>
This paragraph incorrectly conflates "value catego= ry" with "reference-type-ness." I frequently do so myself, i= nformally, but here I think the conflation is a bad thing. Specifically, th= e second bullet seems to be implying that
=C2=A0 =C2=A0 T~ t;
=C2=A0 =C2=A0 forward_to_f(t);
would deduce parameter `x` = as type `T~`, whereas I think really it should be deduced as `T&` becau= se `t` is still an lvalue, even though it is also an owning reference `T~` = in terms of decltype. (I mean, `decltype(t)` is `T~`. I assume. This isn= 9;t covered explicitly anywhere AFAICT.)

(10) Sect= ion 7.3: I think you should explain why=C2=A0>>o.class<Base>=C2=A0should be preferred over the more obvious=C2=A0>>o.Base.

(11) Section 9.2's `remove_range` name and sign= ature don't make any sense to me. Surely the Callback should be passed = by plain old value (STL-style) or by const reference (sane style), and it&#= 39;s the parameter to Callback=C2=A0(not pictured in the signature) = that will be passed by moveable value. Also, this doesn't seem to have = anything to do with the STL's "remove" verb. It seems more li= ke an "erasing=C2=A0[not removing] foreach".
<= div>
(12) Section 9.1 seems to be the most interesting sectio= n for somebody looking to implement `std::optional<T>::optional(optio= nal~)`.=C2=A0 I wouldn't necessarily say that the current Section 7.5 i= s useless, but I do want to see a version of Section 7.5 that shows = how to implement `optional<T>`'s relocating constructor.

HTH,
Arthur

<= /div>
O= n Sat, Feb 9, 2019 at 2:22 PM <dcr= c2cpp@gmail.com> wrote:
A= n updated version of this paper is now at=C2=A0https://github.com/dcrc2cpp/= destructive-move

The main change is that the role of= "owning references" has been downplayed: owning reference variab= les have been renamed "moveable values", and they have been made = more like non-reference variables. They can be initialized from an lvalue o= r rvalue reference, which was previously disallowed - this now calls the co= py constructor or move constructor as appropriate, just as if a non-referen= ce variable was being initialized.

Also the behavi= our of the forwarding operator has been rephrased in terms of changes to th= e scoping rules: the forwarding operator ends the scope of the reference th= at it applies to. Hopefully this better explains what is going on: the comp= iler does not have to track the lifetime of objects - the lifetime of an ob= ject is determined by the scope of the variable that refers to it.

--
You received this message because you are subscribed to a topic in the Goog= le Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this topic, visit https://groups.google.com/a/isocpp.org/d/topic/std-proposals/zVg_bHmtlcU= /unsubscribe.
To unsubscribe from this group and all its topics, send an email to std-prop= osals+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/91aa6796-9935-= 4a02-8021-0e35264811a0%40isocpp.org.

--
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/CADvuK0LaM%= 2BLBuE1OqCMbDbvZBO%3Df%3DDn5z296wYV9rScRvdtN_A%40mail.gmail.com.
--0000000000009bda7b05818cdb07-- .