------=_Part_291_226409279.1467889863290
Content-Type: multipart/alternative;
 boundary="----=_Part_292_443868575.1467889863291"

------=_Part_292_443868575.1467889863291
Content-Type: text/plain; charset=UTF-8

It seems that C++17 will allow us to write "named constructors" even for
non-moveable types due to guaranteed copy elision, e.g.

struct NonMoveable { /* ... */ };
NonMoveable makeNonMoveable() { /* ... */ }

However, named constructors like this one are still very much second-class
citizens when it comes to the standard library. For example, no amount of
copy elision will ever allow us to do this:

std::make_shared<NonMoveable>(makeNonMoveable())

And even if we had a moveable type, calling make_shared with the result of
a named constructor would still incur the cost of a move construction,
which really shouldn't be necessary.

Is there any way to work around this limitation? Perhaps we could do
something like:

struct Helper
{
    operator NonMoveable() { return makeNonMoveable(); }
};
std::make_shared<NonMoveable>(Helper{});

But this seems arcane, and wouldn't necessarily work as a generic solution
(maybe I'm missing something but I think this must break down
if NonMoveable had a poorly-constrained templated constructor).

In the absence of any better workarounds, perhaps we need an alternative to
make_shared, let's call it make_shared_invoke, which takes a callable as
its first argument and invokes that to create the value:

make_shared_invoke(makeNonMoveable)

This would have additional advantages:
(i) It automatically deduces the type of the shared_ptr.
(ii) It's more general than make_shared. For example, it provides an
obvious way to control whether () or {} initialization is used: just use
make_shared_invoke with a lambda.

Of course, it's not just make_shared. Any other library function which
forwards its arguments to a constructor might have the same issue. How
about:

std::deque<NonMoveable> d;
d.emplace_back_invoke(makeNonMoveable);

Any thoughts on this approach, or better alternatives available?

--
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 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/4a30a8de-2e6c-4662-ba31-300d39158486%40isocpp.org.

------=_Part_292_443868575.1467889863291
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>It seems that C++17 will allow us to write &quot;name=
d constructors&quot; even for non-moveable types due to guaranteed copy eli=
sion, e.g.</div><div><br></div><div>struct NonMoveable { /* ... */ };</div>=
<div>NonMoveable makeNonMoveable() { /* ... */ }</div><div><br></div><div>H=
owever, named constructors like this one are still very much second-class c=
itizens when it comes to the standard library. For example, no amount of co=
py elision will ever allow us to do this:</div><div><br></div><div>std::mak=
e_shared&lt;NonMoveable&gt;(makeNonMoveable())</div><div><br></div><div>And=
 even if we had a moveable type, calling make_shared with the result of a n=
amed constructor would still incur=C2=A0the=C2=A0cost of a=C2=A0move constr=
uction, which really shouldn&#39;t be necessary.</div><div><br></div><div>I=
s there any way to work around this limitation? Perhaps we could do somethi=
ng like:</div><div><br></div><div>struct Helper</div><div>{<br>=C2=A0=C2=A0=
=C2=A0 operator NonMoveable() { return makeNonMoveable(); }</div><div>};</d=
iv><div>std::make_shared&lt;NonMoveable&gt;(Helper{});</div><div><br></div>=
<div>But this seems arcane, and wouldn&#39;t necessarily work as a generic =
solution (maybe I&#39;m missing something but I think this must break down =
if=C2=A0NonMoveable had a poorly-constrained templated constructor).</div><=
div><br></div><div>In the absence of any better workarounds, perhaps we nee=
d an alternative to make_shared, let&#39;s call it make_shared_invoke, whic=
h takes a callable as its first argument and invokes that to create the val=
ue:</div><div><br></div><div>make_shared_invoke(makeNonMoveable)</div><div>=
<br></div><div>This would have additional advantages:</div><div>(i) It auto=
matically deduces the type of the shared_ptr.</div><div>(ii) It&#39;s more =
general than make_shared. For example, it provides an obvious way to contro=
l whether () or {} initialization is used: just use make_shared_invoke with=
 a lambda.</div><div><br></div><div>Of course, it&#39;s not just make_share=
d. Any other library function which forwards its arguments to a constructor=
 might have the same issue. How about:</div><div><br></div><div>std::deque&=
lt;NonMoveable&gt; d;</div><div>d.emplace_back_invoke(makeNonMoveable);</di=
v><div><br></div><div>Any thoughts on this approach, or better alternatives=
 available?</div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; 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/4a30a8de-2e6c-4662-ba31-300d39158486%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/4a30a8de-2e6c-4662-ba31-300d39158486=
%40isocpp.org</a>.<br />

------=_Part_292_443868575.1467889863291--

------=_Part_291_226409279.1467889863290--

.

> Il giorno 07 lug 2016, alle ore 13:11, col3435 via ISO C++ Standard - Future Proposals <std-proposals@isocpp.org> ha scritto:
>
> It seems that C++17 will allow us to write "named constructors" even for non-moveable types due to guaranteed copy elision, e.g.
>
> struct NonMoveable { /* ... */ };
> NonMoveable makeNonMoveable() { /* ... */ }
>

Why should copy elision change which types you can return from the function?
If the struct is non-moveable and non-copyable you cannot move nor copy its objects,
whether copy elision is performed or not.

Nicola

--
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 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/54D7644D-0C2E-441B-982E-9CAF3CB6D2AB%40gmail.com.

.

On 7 July 2016 at 14:42, Nicola Gigante <nicola.gigante@gmail.com> wrote:
>
>> Il giorno 07 lug 2016, alle ore 13:11, col3435 via ISO C++ Standard - Future Proposals <std-proposals@isocpp.org> ha scritto:
>>
>> It seems that C++17 will allow us to write "named constructors" even for non-moveable types due to guaranteed copy elision, e.g.
>>
>> struct NonMoveable { /* ... */ };
>> NonMoveable makeNonMoveable() { /* ... */ }
>>
>
> Why should copy elision change which types you can return from the function?

Because when elision becomes mandatory, rather than a possible
optimization, nonmoveable types can be
returned.

> If the struct is non-moveable and non-copyable you cannot move nor copy its objects,
> whether copy elision is performed or not.


With http://open-std.org/JTC1/SC22/WG21/docs/papers/2015/p0135r0.html, you can.

--
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 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/CAFk2RUaRE4i5k6%3D44U0ZRtpUxjgvxW7a5jt-RK47he%2B5So0h%2Bg%40mail.gmail.com.

.

------=_Part_10_649407563.1467898989962
Content-Type: multipart/alternative;
 boundary="----=_Part_11_2065358499.1467898989962"

------=_Part_11_2065358499.1467898989962
Content-Type: text/plain; charset=UTF-8

On Thursday, July 7, 2016 at 7:11:03 AM UTC-4, col...@yahoo.co.uk wrote:
>
> It seems that C++17 will allow us to write "named constructors" even for
> non-moveable types due to guaranteed copy elision, e.g.
>
> struct NonMoveable { /* ... */ };
> NonMoveable makeNonMoveable() { /* ... */ }
>
> However, named constructors like this one are still very much second-class
> citizens when it comes to the standard library. For example, no amount of
> copy elision will ever allow us to do this:
>
> std::make_shared<NonMoveable>(makeNonMoveable())
>
> And even if we had a moveable type, calling make_shared with the result of
> a named constructor would still incur the cost of a move construction,
> which really shouldn't be necessary.
>
> Is there any way to work around this limitation? Perhaps we could do
> something like:
>
> struct Helper
> {
>     operator NonMoveable() { return makeNonMoveable(); }
> };
> std::make_shared<NonMoveable>(Helper{});
>
> But this seems arcane, and wouldn't necessarily work as a generic solution
> (maybe I'm missing something but I think this must break down
> if NonMoveable had a poorly-constrained templated constructor).
>
> In the absence of any better workarounds, perhaps we need an alternative
> to make_shared, let's call it make_shared_invoke, which takes a callable as
> its first argument and invokes that to create the value:
>
> make_shared_invoke(makeNonMoveable)
>
> This would have additional advantages:
> (i) It automatically deduces the type of the shared_ptr.
> (ii) It's more general than make_shared. For example, it provides an
> obvious way to control whether () or {} initialization is used: just use
> make_shared_invoke with a lambda.
>
> Of course, it's not just make_shared. Any other library function which
> forwards its arguments to a constructor might have the same issue. How
> about:
>
> std::deque<NonMoveable> d;
> d.emplace_back_invoke(makeNonMoveable);
>
> Any thoughts on this approach, or better alternatives available?
>

It's an interesting idea in the wake of guaranteed elision. But I think we
need a bit more user-experience with the idiom before we can start
standardizing it.

--
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 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/8d12bb32-d2b8-4751-96b2-10f10a02564d%40isocpp.org.

------=_Part_11_2065358499.1467898989962
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Thursday, July 7, 2016 at 7:11:03 AM UTC-4, col...@yaho=
o.co.uk wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-l=
eft: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"=
><div>It seems that C++17 will allow us to write &quot;named constructors&q=
uot; even for non-moveable types due to guaranteed copy elision, e.g.</div>=
<div><br></div><div>struct NonMoveable { /* ... */ };</div><div>NonMoveable=
 makeNonMoveable() { /* ... */ }</div><div><br></div><div>However, named co=
nstructors like this one are still very much second-class citizens when it =
comes to the standard library. For example, no amount of copy elision will =
ever allow us to do this:</div><div><br></div><div>std::make_shared&lt;NonM=
oveable&gt;(<wbr>makeNonMoveable())</div><div><br></div><div>And even if we=
 had a moveable type, calling make_shared with the result of a named constr=
uctor would still incur=C2=A0the=C2=A0cost of a=C2=A0move construction, whi=
ch really shouldn&#39;t be necessary.</div><div><br></div><div>Is there any=
 way to work around this limitation? Perhaps we could do something like:</d=
iv><div><br></div><div>struct Helper</div><div>{<br>=C2=A0=C2=A0=C2=A0 oper=
ator NonMoveable() { return makeNonMoveable(); }</div><div>};</div><div>std=
::make_shared&lt;NonMoveable&gt;(<wbr>Helper{});</div><div><br></div><div>B=
ut this seems arcane, and wouldn&#39;t necessarily work as a generic soluti=
on (maybe I&#39;m missing something but I think this must break down if=C2=
=A0NonMoveable had a poorly-constrained templated constructor).</div><div><=
br></div><div>In the absence of any better workarounds, perhaps we need an =
alternative to make_shared, let&#39;s call it make_shared_invoke, which tak=
es a callable as its first argument and invokes that to create the value:</=
div><div><br></div><div>make_shared_invoke(<wbr>makeNonMoveable)</div><div>=
<br></div><div>This would have additional advantages:</div><div>(i) It auto=
matically deduces the type of the shared_ptr.</div><div>(ii) It&#39;s more =
general than make_shared. For example, it provides an obvious way to contro=
l whether () or {} initialization is used: just use make_shared_invoke with=
 a lambda.</div><div><br></div><div>Of course, it&#39;s not just make_share=
d. Any other library function which forwards its arguments to a constructor=
 might have the same issue. How about:</div><div><br></div><div>std::deque&=
lt;NonMoveable&gt; d;</div><div>d.emplace_back_invoke(<wbr>makeNonMoveable)=
;</div><div><br></div><div>Any thoughts on this approach, or better alterna=
tives available?</div></div></blockquote><div><br>It&#39;s an interesting i=
dea in the wake of guaranteed elision. But I think we need a bit more user-=
experience with the idiom before we can start standardizing it.<br></div></=
div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; 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/8d12bb32-d2b8-4751-96b2-10f10a02564d%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/8d12bb32-d2b8-4751-96b2-10f10a02564d=
%40isocpp.org</a>.<br />

------=_Part_11_2065358499.1467898989962--

------=_Part_10_649407563.1467898989962--

.

--001a114ea68838bbb705370fcc74
Content-Type: text/plain; charset=UTF-8

On Thu, Jul 7, 2016 at 4:11 AM, col3435 via ISO C++ Standard - Future
Proposals <std-proposals@isocpp.org> wrote:
>
> In the absence of any better workarounds, perhaps we need an alternative
> to make_shared, let's call it make_shared_invoke, which takes a callable as
> its first argument and invokes that to create the value:
>
> make_shared_invoke(makeNonMoveable)
>

This is akin to a solution that I've used over the years in order to
minimize copies/moves and it works very well. Going further, IMO, in an
ideal world any facility in the standard library that does emplacement
should also be able to emplace with the result of a function, but we sort
of missed an easy route forward for that in the standard due to how we
specify emplacement and in-place constructors -- I think that if we wanted
to have a really robust and user-extensible way to do optimal emplacement
in standard-library facilities without introducing additional overloads, we
should have adopted something more similar to the boost in_place_factory
facilities[1] for doing emplacement, only dealing at a more abstract and
formally specified concept-level. Each factory would have an associated
"create" function in addition to or in place of boost's "apply" associated
function. The "create" function would return the constructed object, which
is perfect for use with in-place construction of datamembers from a
constructor in a way that removes the need for copy/move. If we had a
concept like that in the standard and emplacement/in_place-construction
dealt with that concept, it would be trivial to have user-extensible
emplacement that works in a non-intrusive manner with existing containers,
such as a factory that emplaces with a function's result, and it would
isolate handling of std::initializer_list. It also would make it possible
to do things like construct and store an immovable object in a variant,
which is a limitation I'm running into at the moment.

[1]
http://www.boost.org/doc/libs/1_61_0/libs/utility/in_place_factories.html

--
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 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/CANh8DEnjo5x87%2Bd_M_QqvuNCcmqiGbO_%3DDsCO-vfGbMcni9i-A%40mail.gmail.com.

--001a114ea68838bbb705370fcc74
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On T=
hu, Jul 7, 2016 at 4:11 AM, col3435 via ISO C++ Standard - Future Proposals=
 <span dir=3D"ltr">&lt;<a href=3D"mailto:std-proposals@isocpp.org">std-prop=
osals@isocpp.org</a>&gt;</span> wrote:<blockquote class=3D"gmail_quote" sty=
le=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:soli=
d;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><di=
v>In the absence of any better workarounds, perhaps we need an alternative =
to make_shared, let&#39;s call it make_shared_invoke, which takes a callabl=
e as its first argument and invokes that to create the value:</div><div><br=
></div><div>make_shared_invoke(makeNonMoveable)</div></div></blockquote><di=
v><br></div><div>This is akin to a solution that I&#39;ve used over the yea=
rs in order to minimize copies/moves and it works very well. Going further,=
 IMO, in an ideal world any facility in the standard library that does empl=
acement should also be able to emplace with the result of a function, but w=
e sort of missed an easy route forward for that in the standard due to how =
we specify emplacement and in-place constructors -- I think that if we want=
ed to have a really robust and user-extensible way to do optimal emplacemen=
t in standard-library facilities without introducing additional overloads, =
we should have adopted something more similar to the boost in_place_factory=
 facilities[1] for doing emplacement, only dealing at a more abstract and f=
ormally specified concept-level. Each factory would have an associated &quo=
t;create&quot; function in addition to or in place of boost&#39;s &quot;app=
ly&quot; associated function. The &quot;create&quot; function would return =
the constructed object, which is perfect for use with in-place construction=
 of datamembers from a constructor in a way that removes the need for copy/=
move. If we had a concept like that in the standard and emplacement/in_plac=
e-construction dealt with that concept, it would be trivial to have user-ex=
tensible emplacement that works in a non-intrusive manner with existing con=
tainers, such as a factory that emplaces with a function&#39;s result, and =
it would isolate handling of std::initializer_list. It also would make it p=
ossible to do things like construct and store an immovable object in a vari=
ant, which is a limitation I&#39;m running into at the moment.</div><div><b=
r></div><div>[1]=C2=A0<a href=3D"http://www.boost.org/doc/libs/1_61_0/libs/=
utility/in_place_factories.html">http://www.boost.org/doc/libs/1_61_0/libs/=
utility/in_place_factories.html</a></div></div></div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; 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/CANh8DEnjo5x87%2Bd_M_QqvuNCcmqiGbO_%3=
DDsCO-vfGbMcni9i-A%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
>https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CANh8DEnjo5x8=
7%2Bd_M_QqvuNCcmqiGbO_%3DDsCO-vfGbMcni9i-A%40mail.gmail.com</a>.<br />

--001a114ea68838bbb705370fcc74--

.

------=_Part_5889_11446185.1467990231683
Content-Type: multipart/alternative;
 boundary="----=_Part_5890_1459153475.1467990231683"

------=_Part_5890_1459153475.1467990231683
Content-Type: text/plain; charset=UTF-8

On Thursday, July 7, 2016 at 8:24:37 PM UTC+2, Matt Calabrese wrote:
>
> On Thu, Jul 7, 2016 at 4:11 AM, col3435 via ISO C++ Standard - Future
> Proposals <std-pr...@isocpp.org <javascript:>> wrote:
>>
>> In the absence of any better workarounds, perhaps we need an alternative
>> to make_shared, let's call it make_shared_invoke, which takes a callable as
>> its first argument and invokes that to create the value:
>>
>> make_shared_invoke(makeNonMoveable)
>>
>
> This is akin to a solution that I've used over the years in order to
> minimize copies/moves and it works very well. Going further, IMO, in an
> ideal world any facility in the standard library that does emplacement
> should also be able to emplace with the result of a function, but we sort
> of missed an easy route forward for that in the standard due to how we
> specify emplacement and in-place constructors -- I think that if we wanted
> to have a really robust and user-extensible way to do optimal emplacement
> in standard-library facilities without introducing additional overloads, we
> should have adopted something more similar to the boost in_place_factory
> facilities[1] for doing emplacement, only dealing at a more abstract and
> formally specified concept-level. Each factory would have an associated
> "create" function in addition to or in place of boost's "apply" associated
> function. The "create" function would return the constructed object, which
> is perfect for use with in-place construction of datamembers from a
> constructor in a way that removes the need for copy/move. If we had a
> concept like that in the standard and emplacement/in_place-construction
> dealt with that concept, it would be trivial to have user-extensible
> emplacement that works in a non-intrusive manner with existing containers,
> such as a factory that emplaces with a function's result, and it would
> isolate handling of std::initializer_list. It also would make it possible
> to do things like construct and store an immovable object in a variant,
> which is a limitation I'm running into at the moment.
>
> [1]
> http://www.boost.org/doc/libs/1_61_0/libs/utility/in_place_factories.html
>

Note that if you replace the function 'create' with a conversion operator,
you get an implicit lazy function call, which is more likely to work with
existing code.

--
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 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/39fd1de3-e344-4ea8-9a9c-257848f42ade%40isocpp.org.

------=_Part_5890_1459153475.1467990231683
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Thursday, July 7, 2016 at 8:24:37 PM UTC+2, Matt Calabr=
ese wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left:=
 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><di=
v><div class=3D"gmail_quote">On Thu, Jul 7, 2016 at 4:11 AM, col3435 via IS=
O C++ Standard - Future Proposals <span dir=3D"ltr">&lt;<a href=3D"javascri=
pt:" target=3D"_blank" gdf-obfuscated-mailto=3D"38M9WKYvCQAJ" rel=3D"nofoll=
ow" onmousedown=3D"this.href=3D&#39;javascript:&#39;;return true;" onclick=
=3D"this.href=3D&#39;javascript:&#39;;return true;">std-pr...@isocpp.org</a=
>&gt;</span> wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0px 0p=
x 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color=
:rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><div>In the absence of=
 any better workarounds, perhaps we need an alternative to make_shared, let=
&#39;s call it make_shared_invoke, which takes a callable as its first argu=
ment and invokes that to create the value:</div><div><br></div><div>make_sh=
ared_invoke(<wbr>makeNonMoveable)</div></div></blockquote><div><br></div><d=
iv>This is akin to a solution that I&#39;ve used over the years in order to=
 minimize copies/moves and it works very well. Going further, IMO, in an id=
eal world any facility in the standard library that does emplacement should=
 also be able to emplace with the result of a function, but we sort of miss=
ed an easy route forward for that in the standard due to how we specify emp=
lacement and in-place constructors -- I think that if we wanted to have a r=
eally robust and user-extensible way to do optimal emplacement in standard-=
library facilities without introducing additional overloads, we should have=
 adopted something more similar to the boost in_place_factory facilities[1]=
 for doing emplacement, only dealing at a more abstract and formally specif=
ied concept-level. Each factory would have an associated &quot;create&quot;=
 function in addition to or in place of boost&#39;s &quot;apply&quot; assoc=
iated function. The &quot;create&quot; function would return the constructe=
d object, which is perfect for use with in-place construction of datamember=
s from a constructor in a way that removes the need for copy/move. If we ha=
d a concept like that in the standard and emplacement/in_place-<wbr>constru=
ction dealt with that concept, it would be trivial to have user-extensible =
emplacement that works in a non-intrusive manner with existing containers, =
such as a factory that emplaces with a function&#39;s result, and it would =
isolate handling of std::initializer_list. It also would make it possible t=
o do things like construct and store an immovable object in a variant, whic=
h is a limitation I&#39;m running into at the moment.</div><div><br></div><=
div>[1]=C2=A0<a href=3D"http://www.boost.org/doc/libs/1_61_0/libs/utility/i=
n_place_factories.html" target=3D"_blank" rel=3D"nofollow" onmousedown=3D"t=
his.href=3D&#39;http://www.google.com/url?q\x3dhttp%3A%2F%2Fwww.boost.org%2=
Fdoc%2Flibs%2F1_61_0%2Flibs%2Futility%2Fin_place_factories.html\x26sa\x3dD\=
x26sntz\x3d1\x26usg\x3dAFQjCNGWf6-2rsghUbFcMZnUZIsQIiLxUw&#39;;return true;=
" onclick=3D"this.href=3D&#39;http://www.google.com/url?q\x3dhttp%3A%2F%2Fw=
ww.boost.org%2Fdoc%2Flibs%2F1_61_0%2Flibs%2Futility%2Fin_place_factories.ht=
ml\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNGWf6-2rsghUbFcMZnUZIsQIiLxUw&#39=
;;return true;">http://www.boost.org/doc/<wbr>libs/1_61_0/libs/utility/in_<=
wbr>place_factories.html</a></div></div></div></div></blockquote><div><br>N=
ote that if you replace the function &#39;create&#39; with a conversion ope=
rator, you get an implicit lazy function call, which is more likely to work=
 with existing code.<br></div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; 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/39fd1de3-e344-4ea8-9a9c-257848f42ade%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/39fd1de3-e344-4ea8-9a9c-257848f42ade=
%40isocpp.org</a>.<br />

------=_Part_5890_1459153475.1467990231683--

------=_Part_5889_11446185.1467990231683--

.