Topic: Straw polls for P1144R0 "Object relocation in terms
Author: Arthur O'Dwyer <arthur.j.odwyer@gmail.com>
Date: Sun, 11 Nov 2018 17:35:39 -0800 (PST)
Raw View
------=_Part_1720_1228888350.1541986539904
Content-Type: multipart/alternative;
boundary="----=_Part_1721_864235550.1541986539905"
------=_Part_1721_864235550.1541986539905
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
P1144R0 "Object relocation in terms of move plus destroy"=20
<http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p1144r0.html> was=
=20
presented to SG17 (EWGI) in San Diego. (Thanks to Corentin Jabot for trying=
=20
to make it happen!) The paper lists the following straw polls that *could*=
=20
have been taken. None of these polls were taken, and no feedback was given=
=20
on the paper in San Diego.
So I'd like to get *your* opinions! Please reply in this thread with your=
=20
!votes on any or all of the following statements, in the traditional WG21=
=20
straw poll format: "Strongly For" the statement as written; "For" it;=20
"Neutral" (as in, you considered the question and your expert opinion is=20
that you are neutral on it =E2=80=94 please do not use this option as a syn=
onym for=20
*abstaining* due to *lack* of an opinion); "Against" the statement as=20
written; or "Strongly Against" it.
The polls will remain open for one week, until Sunday 2018-11-18. If you=20
don't want your !votes to be public, you can always email them to me=20
privately.
I will tally the ballots and report the results in P1144R1, which will=20
appear in the post-San-Diego mailing (submission deadline: 2018-11-26).
Here are the polls. Please vote in any or all of them, but *only after=20
reading the paper=20
<http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p1144r0.html>.*=20
When a poll says "...as proposed in this paper," it's referring to the=20
formal wording from P1144R0. You would have to read that formal wording to=
=20
know what's being asked!
---------------------------------------
EWG1. We approve of the general idea that user-defined classes should be=20
able to warrant their own trivial relocatability via a standard mechanism.
EWG2. We approve of the general idea that user-defined classes which follow=
=20
the Rule of Zero=20
<https://web.archive.org/web/20130607234833/http://flamingdangerzone.com/cx=
x11/2012/08/15/rule-of-zero.html>=20
should inherit the trivial relocatability of their bases and members.
EWG3. Nobody should be able to warrant the trivial relocatability of class=
=20
`C` except for class `C` itself (i.e., we do not want to see a=20
customization point analogous to `std::hash`).
EWG4. A class should be able to warrant its own trivial relocatability via=
=20
the attribute `[[trivially_relocatable]]`, as proposed in this paper.
EWG5. A class should be able to warrant its own trivial relocatability via=
=20
some attribute, but not necessarily under that exact name.
EWG6. A class should be able to warrant its own trivial relocatability as=
=20
proposed in this paper, but we prefer to see a contextual keyword rather=20
than an attribute.
EWG7. If a trait with the semantics of `is_trivially_relocatable<T>` is=20
added to the `<type_traits>` header, the programmer should be permitted to=
=20
specialize it for program-defined types (i.e., we want to see that trait=20
itself become a customization point analogous to `std::hash`).
EWG8. Trivial relocatability should be assumed by default. Classes such as=
=20
those in Appendix C=20
<http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p1144r0.html#non-t=
rivial-samples>=20
should indicate their non-trivial relocatability via an opt-in mechanism.
EWG9. To simplify conditionally trivial relocation=20
<http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p1144r0.html#sampl=
e-conditional>,=20
if an attribute with the semantics of `[[trivially_relocatable]]` is added,=
=20
it should take a boolean argument.
LEWG10. The algorithm `uninitialized_relocate(first, last, d_first)` should=
=20
be added to the `<memory>` header, as proposed in this paper.
LEWG11. The type trait `is_relocatable<T>` should be added to the=20
`<type_traits>` header, as proposed in this paper.
LEWG12. If `is_relocatable<T>` is added, then we should also add=20
`is_nothrow_relocatable<T>`, as proposed in this paper.
LEWG13. The type trait `is_trivially_relocatable<T>` should be added to the=
=20
`<type_traits>` header, under that exact name, as proposed in this paper.
LEWG14. We approve of a trait with the semantics of=20
`is_trivially_relocatable<T>`, but possibly under a different name. (For=20
example, `is_bitwise_relocatable`.)
LEWG15. If `is_trivially_relocatable<T>` is added, under that exact name,=
=20
then the type trait `is_trivially_swappable<T>` should also be added to the=
=20
`<type_traits>` header.
-----------------------
Discussion and comments on P1144R0 is also welcome =E2=80=94 preferably in =
the=20
original discussion thread=20
<https://groups.google.com/a/isocpp.org/d/msg/sg14/6mAbZOTdVjk/wYaO5wQzBwAJ=
>,=20
or via private email, but if it winds up in this thread, I'm okay with that=
..
Thanks,
Arthur
--=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/a1e4bcd8-592c-4144-8b18-f30e2baafd89%40isocpp.or=
g.
------=_Part_1721_864235550.1541986539905
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div><a href=3D"http://www.open-std.org/jtc1/sc22/wg21/doc=
s/papers/2018/p1144r0.html">P1144R0 "Object relocation in terms of mov=
e plus destroy"</a> was presented to SG17 (EWGI) in San Diego. (Thanks=
to Corentin Jabot for trying to make it happen!) The paper lists the follo=
wing straw polls that <i><b>could</b></i> have been taken. None of these po=
lls were taken, and no feedback was given on the paper in San Diego.</div><=
div><br></div><div>So I'd like to get <i>your</i> opinions! =C2=A0Pleas=
e reply in this thread with your !votes on any or all of the following stat=
ements, in the traditional WG21 straw poll format: "Strongly For"=
the statement as written; "For" it; "Neutral" (as in, =
you considered the question and your expert opinion is that you are neutral=
on it =E2=80=94 please do not use this option as a synonym for=C2=A0<i>abs=
taining</i> due to <i>lack</i> of an opinion); "Against" the stat=
ement as written; or "Strongly Against" it.</div><div><br></div><=
div>The polls will remain open for one week, until Sunday 2018-11-18. If yo=
u don't want your !votes to be public, you can always email them to me =
privately.</div><div>I will tally the ballots and report the results in P11=
44R1, which will appear in the post-San-Diego mailing (submission deadline:=
2018-11-26).</div><div><br></div><div>Here are the polls. Please vote in a=
ny or all of them, but <b>only after <a href=3D"http://www.open-std.org/jtc=
1/sc22/wg21/docs/papers/2018/p1144r0.html">reading the paper</a>.</b> When =
a poll says "...as proposed in this paper," it's referring to=
the formal wording from P1144R0. You would have to read that formal wordin=
g to know what's being asked!</div><div>-------------------------------=
--------</div><div><br></div><div>EWG1. We approve of the general idea that=
user-defined classes should be able to warrant their own trivial relocatab=
ility via a standard mechanism.</div><div><br></div><div>EWG2. We approve o=
f the general idea that user-defined classes which follow the <a href=3D"ht=
tps://web.archive.org/web/20130607234833/http://flamingdangerzone.com/cxx11=
/2012/08/15/rule-of-zero.html">Rule of Zero</a> should inherit the trivial =
relocatability of their bases and members.</div><div><br></div><div>EWG3. N=
obody should be able to warrant the trivial relocatability of class `C` exc=
ept for class `C` itself (i.e., we do not want to see a customization point=
analogous to `std::hash`).</div><div><br></div><div>EWG4. A class should b=
e able to warrant its own trivial relocatability via the attribute `[[trivi=
ally_relocatable]]`, as proposed in this paper.</div><div><br></div><div>EW=
G5. A class should be able to warrant its own trivial relocatability via so=
me attribute, but not necessarily under that exact name.</div><div><br></di=
v><div>EWG6. A class should be able to warrant its own trivial relocatabili=
ty as proposed in this paper, but we prefer to see a contextual keyword rat=
her than an attribute.</div><div><br></div><div>EWG7. If a trait with the s=
emantics of `is_trivially_relocatable<T>` is added to the `<type_t=
raits>` header, the programmer should be permitted to specialize it for =
program-defined types (i.e., we want to see that trait itself become a cust=
omization point analogous to `std::hash`).</div><div><br></div><div>EWG8. T=
rivial relocatability should be assumed by default. Classes such as those i=
n <a href=3D"http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p1144r=
0.html#non-trivial-samples">Appendix C</a> should indicate their non-trivia=
l relocatability via an opt-in mechanism.</div><div><br></div><div>EWG9. To=
simplify <a href=3D"http://www.open-std.org/jtc1/sc22/wg21/docs/papers/201=
8/p1144r0.html#sample-conditional">conditionally trivial relocation</a>, if=
an attribute with the semantics of `[[trivially_relocatable]]` is added, i=
t should take a boolean argument.</div><div><br></div><div>LEWG10. The algo=
rithm `uninitialized_relocate(first, last, d_first)` should be added to the=
`<memory>` header, as proposed in this paper.</div><div><br></div><d=
iv>LEWG11. The type trait `is_relocatable<T>` should be added to the =
`<type_traits>` header, as proposed in this paper.</div><div><br></di=
v><div>LEWG12. If `is_relocatable<T>` is added, then we should also a=
dd `is_nothrow_relocatable<T>`, as proposed in this paper.</div><div>=
<br></div><div>LEWG13. The type trait `is_trivially_relocatable<T>` s=
hould be added to the `<type_traits>` header, under that exact name, =
as proposed in this paper.</div><div><br></div><div>LEWG14. We approve of a=
trait with the semantics of `is_trivially_relocatable<T>`, but possi=
bly under a different name. (For example, `is_bitwise_relocatable`.)</div><=
div><br></div><div>LEWG15. If `is_trivially_relocatable<T>` is added,=
under that exact name, then the type trait `is_trivially_swappable<T>=
;` should also be added to the `<type_traits>` header.</div><div><br>=
</div><div>-----------------------</div><div><br></div><div>Discussion and =
comments on P1144R0 is also welcome =E2=80=94 preferably=C2=A0<a href=3D"ht=
tps://groups.google.com/a/isocpp.org/d/msg/sg14/6mAbZOTdVjk/wYaO5wQzBwAJ">i=
n the original discussion thread</a>, or via private email, but if it winds=
up in this thread, I'm okay with that.</div><div><br></div><div>Thanks=
,</div><div>Arthur</div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/a1e4bcd8-592c-4144-8b18-f30e2baafd89%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/a1e4bcd8-592c-4144-8b18-f30e2baafd89=
%40isocpp.org</a>.<br />
------=_Part_1721_864235550.1541986539905--
------=_Part_1720_1228888350.1541986539904--
.