LWG2754 The in_place constructors and emplace functions added by P0032R3 don't require CopyConstructible #1072

jwakely · 2016-11-18T16:54:48Z

Also includes the changes to [ans.cons] p9 from P0504R0 (LWG Motion 19)
which modify the same paragraph.

burblebee · 2016-11-18T19:59:29Z

source/utilities.tex

-if \tcode{decay_t<ValueType>} is the same type as \tcode{any} or
-if \tcode{ValueType} is a specialization of \tcode{in_place_type_t}.
+This constructor shall not participate in overload resolution unless
+\tcode{T} is the same type as \tcode{any},


is not the same??

Oops, thanks.

burblebee · 2016-11-18T20:02:20Z

source/utilities.tex

 \end{itemdecl}

 \begin{itemdescr}
 \pnum
+Let \tcode{T} be equal to \tcode{decay_t<ValueType>}.


I would leave out "equal to" - it's not in the paper, it's inconsistent with other "Let"s, and it adds nothing.

I added it in to be consistent with what was already there, e.g.

draft/source/utilities.tex

Line 4960 in ef536ae

Let \tcode{T} be equal to \tcode{decay_t<ValueType>}.

(which is, at the time of writing, current master)

I dislike "equal to" for a typedef though, so I'll change it. I quite like "shall denote" that we use elsewhere, but will just go with "Let T be decay_t<ValueType>"

And it is in LWG 2754, for better or worse.

Changed and force pushed.

It's NOT in 2754 - you must be looking at the superceded versions. See http://wg21.cmeerw.net/lwg/issue2754 (or skip past the superceded versions in http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0165r3.html).

Oops, you're right, I was looking at the superseded version. Although confusingly, the final version says "Let T be decay_t<ValueType>." even for the existing text that isn't changed (which is wrong). Bah. Anyway, I changed it.

burblebee · 2016-11-18T20:05:49Z

source/utilities.tex

+\remarks
+This constructor shall not participate in overload resolution unless
+\tcode{is_copy_constructible_v<T>} is \tcode{true}
+and \tcode{is_constructible_v<T, Args...>} is \tcode{true}.


fyi, folks usually put the conjunction ("and" in this case) at the end of the previous line. not that you need to change it here, but I try to keep the spec coding style consistent (I'm sure you've noticed we have a long way to go there!)

On second thought, can you go ahead and make this change anyway? (there are several occurrences in this patch) since this will be rebased anyway, might as well try to be consistent from the start :)

I.e. do:
bla bla and
bla bla

FWIW I think that's the wrong choice, because if we have an Oxford comma then it seems natural to put the line break after the comma, and start the next line with the conjunction.

It also involves more editing for cases like:

case one, case two, case three, and case four.

If you want to add a new case between three and four you have to edit an existing line, not just insert a new one:

case one, case two, case three, <DEL>and<DEL> <INS>case three-point-five, and</INS> case four.

Changed and force pushed.

You make a good point. I was simply following existing style - I will switch to doing things your way from now on, assuming others agree. Any one else have a preference?

so you did change things after all... what do we want to stick with as a group? When reading the Latex, I like the conjunction the previous line. I like the way it lines up :)

burblebee · 2016-11-18T20:06:35Z

source/utilities.tex

 \end{itemdecl}

 \begin{itemdescr}
 \pnum
+Let \tcode{T} be equal to \tcode{decay_t<ValueType>}.


same with "equal to" here

burblebee · 2016-11-18T20:08:56Z

source/utilities.tex

  void emplace(Args&&... args);
 \end{itemdecl}

 \begin{itemdescr}
 \pnum
-\requires \tcode{is_constructible_v<T, Args...>} is \tcode{true}.
+Let \tcode{T} be equal to \tcode{decay_t<ValueType>}.


ditto for "equal to"

burblebee · 2016-11-18T20:10:01Z

source/utilities.tex

  void emplace(initializer_list<U> il, Args&&... args);
 \end{itemdecl}

 \begin{itemdescr}
 \pnum
+Let \tcode{T} be equal to \tcode{decay_t<ValueType>}.


ditto for "equal to"

…2R3 don't require CopyConstructible Also includes the changes to [ans.cons] p9 from P0504R0 (LWG Motion 19) which modify the same paragraph.

burblebee · 2016-11-19T00:24:40Z

This is ready to go now right? Can you merge it into the motions branch? Or maybe I should ask: if I clicked "squash and merge", would it go to the motions branch or master?

burblebee · 2016-11-19T00:25:43Z

Hmm - probably shouldn't have closed until you committed right?

burblebee · 2016-11-19T00:27:40Z

I see - you can tell the base from the line at the top:

"wants to merge 1 commit into cplusplus:motions-2016-11-lwg-11 from jwakely:motions-2016-11-lwg-11"

So this will go to the motions branch. Great - will merge then...

jwakely · 2016-11-19T00:42:51Z

Yep, I created the pull request so it would only add to the branch, not master - thanks!

burblebee reviewed Nov 18, 2016

View reviewed changes

burblebee force-pushed the motions-2016-11-lwg-11 branch from 8366e9e to f84cd47 Compare November 18, 2016 21:11

jwakely force-pushed the motions-2016-11-lwg-11 branch 2 times, most recently from e5153d0 to ec4e433 Compare November 18, 2016 23:26

LWG2754 The in_place constructors and emplace functions added by P003…

be1a013

…2R3 don't require CopyConstructible Also includes the changes to [ans.cons] p9 from P0504R0 (LWG Motion 19) which modify the same paragraph.

jwakely force-pushed the motions-2016-11-lwg-11 branch from ec4e433 to be1a013 Compare November 18, 2016 23:37

burblebee closed this Nov 19, 2016

burblebee reopened this Nov 19, 2016

burblebee merged commit e55bde8 into cplusplus:motions-2016-11-lwg-11 Nov 19, 2016

jwakely deleted the motions-2016-11-lwg-11 branch November 19, 2016 00:42

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

LWG2754 The in_place constructors and emplace functions added by P0032R3 don't require CopyConstructible #1072

LWG2754 The in_place constructors and emplace functions added by P0032R3 don't require CopyConstructible #1072

jwakely commented Nov 18, 2016

burblebee Nov 18, 2016

jwakely Nov 18, 2016

burblebee Nov 18, 2016

jwakely Nov 18, 2016 •

edited

jwakely Nov 18, 2016

jwakely Nov 18, 2016

burblebee Nov 18, 2016

jwakely Nov 18, 2016

burblebee Nov 18, 2016 •

edited

jwakely Nov 18, 2016

jwakely Nov 18, 2016

burblebee Nov 18, 2016

burblebee Nov 18, 2016

burblebee Nov 18, 2016

burblebee Nov 18, 2016

burblebee Nov 18, 2016

burblebee commented Nov 19, 2016

burblebee commented Nov 19, 2016

burblebee commented Nov 19, 2016

jwakely commented Nov 19, 2016

LWG2754 The in_place constructors and emplace functions added by P0032R3 don't require CopyConstructible #1072

LWG2754 The in_place constructors and emplace functions added by P0032R3 don't require CopyConstructible #1072

Conversation

jwakely commented Nov 18, 2016

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

jwakely Nov 18, 2016 • edited

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

burblebee Nov 18, 2016 • edited

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

burblebee commented Nov 19, 2016

burblebee commented Nov 19, 2016

burblebee commented Nov 19, 2016

jwakely commented Nov 19, 2016

jwakely Nov 18, 2016 •

edited

burblebee Nov 18, 2016 •

edited