------=_Part_2360_1450864764.1468450064533
Content-Type: multipart/alternative;
 boundary="----=_Part_2361_1036331333.1468450064533"

------=_Part_2361_1036331333.1468450064533
Content-Type: text/plain; charset=UTF-8

Hi all,

This is a cross posting from the SG14 reflector, regarding a draft proposal
some of us are working on.

Very briefly, some of us are interested in having a standardized function
which does not incur an upfront memory allocation to store the callable
target, instead opting for a compile time specified buffer (stack
allocated). This has been quite useful in several low latency domains such
as gaming and electronic trading. In other words, a drop-in replacement for
std::function, where all data is on the stack.

The original post is
here: https://groups.google.com/a/isocpp.org/d/topic/sg14/1Sw_qEdIYes/discussion

The resultant draft proposal is
here: https://github.com/WG21-SG14/SG14/blob/master/Docs/Proposals/NonAllocatingStandardFunction.pdf

Please feel free to comment here or in the SG14 reflector. This is still
very much in the draft stage, and all feedback is appreciated. The
reference implementation is still a work in progress
(https://github.com/WG21-SG14/SG14/blob/master/SG14/inplace_function.h).

Many thanks,
Carl

--
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/e00db911-40f5-4c11-a4b8-32bba77aa0a5%40isocpp.org.

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

<div dir=3D"ltr">Hi all,<div><br></div><div>This is a cross posting from th=
e SG14 reflector, regarding a draft proposal some of us are working on.</di=
v><div><br></div><div>Very briefly, some of us are interested in having a s=
tandardized function which does not incur an upfront memory allocation to s=
tore the callable target, instead opting for a compile time specified buffe=
r (stack allocated). This has been quite useful in several low latency doma=
ins such as gaming and electronic trading. In other words, a drop-in replac=
ement for std::function, where all data is on the stack.<br></div><div><br>=
</div><div>The original post is here:=C2=A0https://groups.google.com/a/isoc=
pp.org/d/topic/sg14/1Sw_qEdIYes/discussion</div><div><br></div><div>The res=
ultant draft proposal is here:=C2=A0https://github.com/WG21-SG14/SG14/blob/=
master/Docs/Proposals/NonAllocatingStandardFunction.pdf=C2=A0</div><div><br=
></div><div>Please feel free to comment here or in the SG14 reflector. This=
 is still very much in the draft stage, and all feedback is appreciated. Th=
e reference implementation is still a work in progress (https://github.com/=
WG21-SG14/SG14/blob/master/SG14/inplace_function.h).</div><div><br></div><d=
iv>Many thanks,</div><div>Carl</div><div><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/e00db911-40f5-4c11-a4b8-32bba77aa0a5%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/e00db911-40f5-4c11-a4b8-32bba77aa0a5=
%40isocpp.org</a>.<br />

------=_Part_2361_1036331333.1468450064533--

------=_Part_2360_1450864764.1468450064533--

.

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

On 13 July 2016 at 17:47, Carl Cook <carl.cook@gmail.com> wrote:

> Very briefly, some of us are interested in having a standardized function
> which does not incur an upfront memory allocation to store the callable
> target, instead opting for a compile time specified buffer (stack
> allocated).
>

I don't think you mean stack allocated; I think you mean the space is
embedded in the object (aka the small object optimization).  If the object
is allocated on the heap, the space will also be in the heap, correct?
--
 Nevin ":-)" Liber  <mailto:nevin@eviloverlord.com>  +1-847-691-1404

--
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/CAGg_6%2BM9vzOf%2BwE9BbKQzA%3Dfp%2Bsh0_Kzz4WmbMC4Sa30Oq5Ucg%40mail.gmail.com.

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

<div dir=3D"ltr">On 13 July 2016 at 17:47, Carl Cook <span dir=3D"ltr">&lt;=
<a href=3D"mailto:carl.cook@gmail.com" target=3D"_blank">carl.cook@gmail.co=
m</a>&gt;</span> wrote:<br><div class=3D"gmail_extra"><div class=3D"gmail_q=
uote"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-l=
eft:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div>Very briefly, so=
me of us are interested in having a standardized function which does not in=
cur an upfront memory allocation to store the callable target, instead opti=
ng for a compile time specified buffer (stack allocated).</div></div></bloc=
kquote><div><br></div><div>I don&#39;t think you mean stack allocated; I th=
ink you mean the space is embedded in the object (aka the small object opti=
mization).=C2=A0 If the object is allocated on the heap, the space will als=
o be in the heap, correct?</div></div>-- <br><div class=3D"gmail_signature"=
 data-smartmail=3D"gmail_signature"><div dir=3D"ltr"><div><div dir=3D"ltr">=
<div>=C2=A0Nevin &quot;:-)&quot; Liber=C2=A0 &lt;mailto:<a href=3D"mailto:n=
evin@eviloverlord.com" target=3D"_blank">nevin@eviloverlord.com</a>&gt; =C2=
=A0+1-847-691-1404</div></div></div></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/CAGg_6%2BM9vzOf%2BwE9BbKQzA%3Dfp%2Bsh=
0_Kzz4WmbMC4Sa30Oq5Ucg%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfoo=
ter">https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAGg_6%2B=
M9vzOf%2BwE9BbKQzA%3Dfp%2Bsh0_Kzz4WmbMC4Sa30Oq5Ucg%40mail.gmail.com</a>.<br=
 />

--001a11353f76c3447b05378c465f--

.

--047d7b86cbda03027c05378c53df
Content-Type: text/plain; charset=UTF-8

On 14 July 2016 at 00:54, Nevin Liber <nevin@eviloverlord.com> wrote:
>
> I don't think you mean stack allocated; I think you mean the space is
> embedded in the object (aka the small object optimization).  If the object
> is allocated on the heap, the space will also be in the heap, correct?
>

100% correct, thanks. I'll fix this up now.

--
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/CAGa0LWsB%2B1RnMZ%3DsBL8q38oWbv8orC6RarsWe%2B%2BmiTeteTikvA%40mail.gmail.com.

--047d7b86cbda03027c05378c53df
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 1=
4 July 2016 at 00:54, Nevin Liber <span dir=3D"ltr">&lt;<a href=3D"mailto:n=
evin@eviloverlord.com" target=3D"_blank">nevin@eviloverlord.com</a>&gt;</sp=
an> wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bord=
er-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div class=3D"gma=
il_extra"><div class=3D"gmail_quote"><div>I don&#39;t think you mean stack =
allocated; I think you mean the space is embedded in the object (aka the sm=
all object optimization).=C2=A0 If the object is allocated on the heap, the=
 space will also be in the heap, correct?</div></div></div></div></blockquo=
te><div><br></div><div>100% correct, thanks. I&#39;ll fix this up now.=C2=
=A0</div></div><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/CAGa0LWsB%2B1RnMZ%3DsBL8q38oWbv8orC6R=
arsWe%2B%2BmiTeteTikvA%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfoo=
ter">https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAGa0LWsB=
%2B1RnMZ%3DsBL8q38oWbv8orC6RarsWe%2B%2BmiTeteTikvA%40mail.gmail.com</a>.<br=
 />

--047d7b86cbda03027c05378c53df--

.

Em quarta-feira, 13 de julho de 2016, =C3=A0s 15:47:44 PDT, Carl Cook escre=
veu:
> Hi all,
>=20
> This is a cross posting from the SG14 reflector, regarding a draft propos=
al
> some of us are working on.
>=20
> Very briefly, some of us are interested in having a standardized function
> which does not incur an upfront memory allocation to store the callable
> target, instead opting for a compile time specified buffer (stack
> allocated). This has been quite useful in several low latency domains suc=
h
> as gaming and electronic trading. In other words, a drop-in replacement f=
or
> std::function, where all data is on the stack.
>=20
> The original post is
> here:
> https://groups.google.com/a/isocpp.org/d/topic/sg14/1Sw_qEdIYes/discussio=
n
>=20
> The resultant draft proposal is
> here:
> https://github.com/WG21-SG14/SG14/blob/master/Docs/Proposals/NonAllocatin=
gS
> tandardFunction.pdf

Hi Carl

Can you explain somewhere why std::function is unable to do that?

In other words, why must std::function allocate memory?

--=20
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center

--=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/4948193.1toAHviMXG%40tjmaciei-mobl1.

.

On 14 July 2016 at 02:22, Thiago Macieira <thiago@macieira.org> wrote:
> Em quarta-feira, 13 de julho de 2016, =C3=A0s 15:47:44 PDT, Carl Cook esc=
reveu:
>> Hi all,
>>
>> This is a cross posting from the SG14 reflector, regarding a draft propo=
sal
>> some of us are working on.
>>
>> Very briefly, some of us are interested in having a standardized functio=
n
>> which does not incur an upfront memory allocation to store the callable
>> target, instead opting for a compile time specified buffer (stack
>> allocated). This has been quite useful in several low latency domains su=
ch
>> as gaming and electronic trading. In other words, a drop-in replacement =
for
>> std::function, where all data is on the stack.
>>
>> The original post is
>> here:
>> https://groups.google.com/a/isocpp.org/d/topic/sg14/1Sw_qEdIYes/discussi=
on
>>
>> The resultant draft proposal is
>> here:
>> https://github.com/WG21-SG14/SG14/blob/master/Docs/Proposals/NonAllocati=
ngS
>> tandardFunction.pdf
>
> Hi Carl
>
> Can you explain somewhere why std::function is unable to do that?
>
> In other words, why must std::function allocate memory?


Because it does type erasure and can hold a functor of any size, and
can be assigned to from another functor
of any size. Presumably this new type would fail to initialize if a
functor larger than the internal buffer is used
for initialization or assignment.

--=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/CAFk2RUaOii3qgGA7jDZJV6oE-3eoDAQKhmrO8DpUbB3ZVDF=
6Qg%40mail.gmail.com.

.

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

On Thu, Jul 14, 2016 at 12:22 AM, Thiago Macieira <thiago@macieira.org>
wrote:

> Hi Carl
>
> Can you explain somewhere why std::function is unable to do that?
>
> In other words, why must std::function allocate memory?
>

I think the issue is not that it "must allocate", rather that it's not
required to embed and provides no way for the user to ensure embedding, and
typical implementations don't provide enough in-object space for Carl and
co's cases.

--
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/CACGiwhGs-L-NRCc-gmAFrh2FrY7r%2BF3zxzr3wTdBkCmvvSiSug%40mail.gmail.com.

--001a1130cf323729f205378cb790
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 14, 2016 at 12:22 AM, Thiago Macieira <span dir=3D"ltr">&lt;<a href=
=3D"mailto:thiago@macieira.org" target=3D"_blank">thiago@macieira.org</a>&g=
t;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0=
 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=3D"">
</span>Hi Carl<br>
<br>
Can you explain somewhere why std::function is unable to do that?<br>
<br>
In other words, why must std::function allocate memory?<br></blockquote><di=
v><br></div><div>I think the issue is not that it &quot;must allocate&quot;=
, rather that it&#39;s not required to embed and provides no way for the us=
er to ensure embedding, and typical implementations don&#39;t provide enoug=
h in-object space for Carl and co&#39;s cases.<br></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/CACGiwhGs-L-NRCc-gmAFrh2FrY7r%2BF3zxz=
r3wTdBkCmvvSiSug%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CACGiwhGs-L-NRC=
c-gmAFrh2FrY7r%2BF3zxzr3wTdBkCmvvSiSug%40mail.gmail.com</a>.<br />

--001a1130cf323729f205378cb790--

.

Em quinta-feira, 14 de julho de 2016, =C3=A0s 02:26:17 PDT, Ville Voutilain=
en=20
escreveu:
> > Hi Carl
> >=20
> > Can you explain somewhere why std::function is unable to do that?
> >=20
> > In other words, why must std::function allocate memory?
>=20
> Because it does type erasure and can hold a functor of any size, and
> can be assigned to from another functor
> of any size. Presumably this new type would fail to initialize if a
> functor larger than the internal buffer is used
> for initialization or assignment.

Ah, I see: functors (incl. lambdas). I was thinking of function pointers an=
d=20
PMFs. Functors can have an arbitrary size, so no std::function implementati=
on=20
can be wide enough to hold all possibilities.

But as a matter of QoI, std::function should not allocate for regular funct=
ion=20
pointers and PMFs, plus stateless functors & lambdas.

--=20
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center

--=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/9925907.dlQ8qs8rgK%40tjmaciei-mobl1.

.

> Very briefly, some of us are interested in having a standardized
> function which does not incur an upfront memory allocation to store
> the callable target, instead opting for a compile time specified
> buffer (stack allocated). This has been quite useful in several low
> latency domains such as gaming and electronic trading. In other words,
> a drop-in replacement for std::function, where all data is on the
> stack.

Isn't this already possible by using today's `std::function` with a
custom allocator backed by a stack-based array?  The only thing this
solution cannot easily do for you is checking statically that the buffer
is large enough but since the size of an object is a constant, a single
unit test that passes control flow through the creation of the
type-erased function object would give that assurance to you.

`std::function` type-erases the allocator as well but I'd be very
disappointed if this would mean a heap allocation for a simple stack
allocator with a state as small as two pointers.  I'm not able to point
to a source that confirms this, though.

It's likely that if you care about `std::function` not calling `malloc`,
you probably care about small (but still too large for SSO) and
short-lived strings and similar stuff, too.  Custom allocators provide a
uniform interface to this without having to re-implement each type as a
stack-based alternative.

Am I missing something essential that your proposed
`std::inplace_function` can do in addition?

--
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/871t2xqbb5.fsf%40gmail.com.

.

------=_Part_76_678687218.1468462540724
Content-Type: multipart/alternative;
 boundary="----=_Part_77_800067329.1468462540724"

------=_Part_77_800067329.1468462540724
Content-Type: text/plain; charset=UTF-8

On Wednesday, July 13, 2016 at 9:05:06 PM UTC-4, Moritz Klammler wrote:
>
> > Very briefly, some of us are interested in having a standardized
> > function which does not incur an upfront memory allocation to store
> > the callable target, instead opting for a compile time specified
> > buffer (stack allocated). This has been quite useful in several low
> > latency domains such as gaming and electronic trading. In other words,
> > a drop-in replacement for std::function, where all data is on the
> > stack.
>
> Isn't this already possible by using today's `std::function` with a
> custom allocator backed by a stack-based array?


I'm not clear as to what you mean here. Consider this:

std::function<void()> a_func()
{
  return []{};
}

What would the "stack-based array" equivalent look like? Would it look as
reasonable as this? Would it be able to use that nifty guaranteed elision
stuff we'll be getting?

--
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/b8ca2bb9-2446-4640-8c40-df6566473f0b%40isocpp.org.

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

<div dir=3D"ltr">On Wednesday, July 13, 2016 at 9:05:06 PM UTC-4, Moritz Kl=
ammler wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-le=
ft: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">&gt; Very briefly=
, some of us are interested in having a standardized
<br>&gt; function which does not incur an upfront memory allocation to stor=
e
<br>&gt; the callable target, instead opting for a compile time specified
<br>&gt; buffer (stack allocated). This has been quite useful in several lo=
w
<br>&gt; latency domains such as gaming and electronic trading. In other wo=
rds,
<br>&gt; a drop-in replacement for std::function, where all data is on the
<br>&gt; stack.
<br>
<br>Isn&#39;t this already possible by using today&#39;s `std::function` wi=
th a
<br>custom allocator backed by a stack-based array?</blockquote><div><br>I&=
#39;m not clear as to what you mean here. Consider this:<br><br><div class=
=3D"prettyprint" style=3D"background-color: rgb(250, 250, 250); border-colo=
r: rgb(187, 187, 187); border-style: solid; border-width: 1px; word-wrap: b=
reak-word;"><code class=3D"prettyprint"><div class=3D"subprettyprint"><span=
 style=3D"color: #000;" class=3D"styled-by-prettify">std</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">::</span><span style=3D"colo=
r: #008;" class=3D"styled-by-prettify">function</span><span style=3D"color:=
 #660;" class=3D"styled-by-prettify">&lt;</span><span style=3D"color: #008;=
" class=3D"styled-by-prettify">void</span><span style=3D"color: #660;" clas=
s=3D"styled-by-prettify">()&gt;</span><span style=3D"color: #000;" class=3D=
"styled-by-prettify"> a_func</span><span style=3D"color: #660;" class=3D"st=
yled-by-prettify">()</span><span style=3D"color: #000;" class=3D"styled-by-=
prettify"><br></span><span style=3D"color: #660;" class=3D"styled-by-pretti=
fy">{</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br>=
=C2=A0 </span><span style=3D"color: #008;" class=3D"styled-by-prettify">ret=
urn</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span=
><span style=3D"color: #660;" class=3D"styled-by-prettify">[]{};</span><spa=
n style=3D"color: #000;" class=3D"styled-by-prettify"><br></span><span styl=
e=3D"color: #660;" class=3D"styled-by-prettify">}</span></div></code></div>=
<br>What would the &quot;stack-based array&quot; equivalent look like? Woul=
d it look as reasonable as this? Would it be able to use that nifty guarant=
eed elision stuff we&#39;ll be getting?<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/b8ca2bb9-2446-4640-8c40-df6566473f0b%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/b8ca2bb9-2446-4640-8c40-df6566473f0b=
%40isocpp.org</a>.<br />

------=_Part_77_800067329.1468462540724--

------=_Part_76_678687218.1468462540724--

.

------=_Part_14_2089011895.1468463141100
Content-Type: multipart/alternative;
 boundary="----=_Part_15_1052940931.1468463141100"

------=_Part_15_1052940931.1468463141100
Content-Type: text/plain; charset=UTF-8

First, would it be possible to make this proposal available via a PDF *not*
hosted on GitHub? Like maybe on a github.io page or something, where I can
view it in my browser instead of having to download it?

Next, I don't believe something like this belongs in the standard. I'm not
saying that it isn't a useful class. But its utility is *really* special
case. Much like a string with a user-specified SSO size and so forth. Not a
bad idea, but just not good for the standard.

I really think it would be a good idea to have some form of "special
case/low level/etc TS" for these kinds of types. Like the library
fundamentals TS, but without the expectation that it would ever go into the
standard wholesale.

As to the idea itself... I'm not really sure about it. My main concern is
this:

std::inplace_function<int(), VALUE> func()
{
  return [x = 12]() {return x;};
}

What can I set `VALUE` to which will *guarantee* that this code compiles?
Because I don't think the standard gives us a way to do that. Oh sure, from
a practical perspective, we can make some guesses about the size of the
lambda type. But even so, it's not clear that any particular `VALUE` would
permit compilation.

--
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/2813901a-dc9d-4c4f-ae07-21a16c0b0da2%40isocpp.org.

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

<div dir=3D"ltr">First, would it be possible to make this proposal availabl=
e via a PDF <i>not</i>
 hosted on GitHub? Like maybe on a github.io page or something, where I=20
can view it in my browser instead of having to download it?<br><br>Next, I =
don&#39;t believe something like this belongs in the standard. I&#39;m not =
saying that it isn&#39;t a useful class. But its utility is <i>really</i> s=
pecial case. Much like a string with a user-specified SSO size and so forth=
.. Not a bad idea, but just not good for the standard.<br><br>I really think=
 it would be a good idea to have some form of &quot;special case/low level/=
etc TS&quot; for these kinds of types. Like the library fundamentals TS, bu=
t without the expectation that it would ever go into the standard wholesale=
..<br><br>As to the idea itself... I&#39;m not really sure about it. My main=
 concern is this:<br><br><div class=3D"prettyprint" style=3D"background-col=
or: rgb(250, 250, 250); border-color: rgb(187, 187, 187); border-style: sol=
id; border-width: 1px; word-wrap: break-word;"><code class=3D"prettyprint">=
<div class=3D"subprettyprint"><span style=3D"color: #000;" class=3D"styled-=
by-prettify">std</span><span style=3D"color: #660;" class=3D"styled-by-pret=
tify">::</span><span style=3D"color: #000;" class=3D"styled-by-prettify">in=
place_function</span><span style=3D"color: #660;" class=3D"styled-by-pretti=
fy">&lt;</span><span style=3D"color: #008;" class=3D"styled-by-prettify">in=
t</span><span style=3D"color: #660;" class=3D"styled-by-prettify">(),</span=
><span style=3D"color: #000;" class=3D"styled-by-prettify"> VALUE</span><sp=
an style=3D"color: #660;" class=3D"styled-by-prettify">&gt;</span><span sty=
le=3D"color: #000;" class=3D"styled-by-prettify"> func</span><span style=3D=
"color: #660;" class=3D"styled-by-prettify">()</span><span style=3D"color: =
#000;" class=3D"styled-by-prettify"><br></span><span style=3D"color: #660;"=
 class=3D"styled-by-prettify">{</span><span style=3D"color: #000;" class=3D=
"styled-by-prettify"><br>=C2=A0 </span><span style=3D"color: #008;" class=
=3D"styled-by-prettify">return</span><span style=3D"color: #000;" class=3D"=
styled-by-prettify"> </span><span style=3D"color: #660;" class=3D"styled-by=
-prettify">[</span><span style=3D"color: #000;" class=3D"styled-by-prettify=
">x </span><span style=3D"color: #660;" class=3D"styled-by-prettify">=3D</s=
pan><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span=
 style=3D"color: #066;" class=3D"styled-by-prettify">12</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">]()</span><span style=3D"col=
or: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #660;=
" class=3D"styled-by-prettify">{</span><span style=3D"color: #008;" class=
=3D"styled-by-prettify">return</span><span style=3D"color: #000;" class=3D"=
styled-by-prettify"> x</span><span style=3D"color: #660;" class=3D"styled-b=
y-prettify">;};</span><span style=3D"color: #000;" class=3D"styled-by-prett=
ify"><br></span><span style=3D"color: #660;" class=3D"styled-by-prettify">}=
</span></div></code></div><br>What can I set `VALUE` to which will <i>guara=
ntee</i> that this code compiles? Because I don&#39;t think the standard gi=
ves us a way to do that. Oh sure, from a practical perspective, we can make=
 some guesses about the size of the lambda type. But even so, it&#39;s not =
clear that any particular `VALUE` would permit compilation.<br></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/2813901a-dc9d-4c4f-ae07-21a16c0b0da2%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/2813901a-dc9d-4c4f-ae07-21a16c0b0da2=
%40isocpp.org</a>.<br />

------=_Part_15_1052940931.1468463141100--

------=_Part_14_2089011895.1468463141100--

.

On 7/13/2016 9:25 PM, Nicol Bolas wrote:
> First, would it be possible to make this proposal available via a PDF
> /not/ hosted on GitHub? Like maybe on a github.io page or something,
> where I can view it in my browser instead of having to download it?

I see it in-line in my browser, but if that doesn't work for you, you
can use rawgit:
<https://cdn.rawgit.com/WG21-SG14/SG14/master/Docs/Proposals/NonAllocatingStandardFunction.pdf>.

- Jim


--
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/nm77ni%24uha%241%40ger.gmane.org.

.

------=_Part_23_1223753247.1468475912469
Content-Type: multipart/alternative;
 boundary="----=_Part_24_856620174.1468475912469"

------=_Part_24_856620174.1468475912469
Content-Type: text/plain; charset=UTF-8



On Wednesday, July 13, 2016 at 9:05:06 PM UTC-4, Moritz Klammler wrote:
>
> > Very briefly, some of us are interested in having a standardized
> > function which does not incur an upfront memory allocation to store
> > the callable target, instead opting for a compile time specified
> > buffer (stack allocated). This has been quite useful in several low
> > latency domains such as gaming and electronic trading. In other words,
> > a drop-in replacement for std::function, where all data is on the
> > stack.
>
> Isn't this already possible by using today's `std::function` with a
> custom allocator backed by a stack-based array?  The only thing this
> solution cannot easily do for you is checking statically that the buffer
> is large enough but since the size of an object is a constant, a single
> unit test that passes control flow through the creation of the
> type-erased function object would give that assurance to you.
>
> `std::function` type-erases the allocator as well but I'd be very
> disappointed if this would mean a heap allocation for a simple stack
> allocator with a state as small as two pointers.  I'm not able to point
> to a source that confirms this, though.
>
> It's likely that if you care about `std::function` not calling `malloc`,
> you probably care about small (but still too large for SSO) and
> short-lived strings and similar stuff, too.  Custom allocators provide a
> uniform interface to this without having to re-implement each type as a
> stack-based alternative.
>
> Am I missing something essential that your proposed
> `std::inplace_function` can do in addition?
>

The allocator support in std::function has been zapped as of three weeks
ago.

Also, passing such a thing around is trickier since the array's lifetime is
independent of the std::function.

--
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/28284ab7-1046-4631-bb4c-f755ce96c2e3%40isocpp.org.

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

<div dir=3D"ltr"><br><br>On Wednesday, July 13, 2016 at 9:05:06 PM UTC-4, M=
oritz Klammler wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;m=
argin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">&gt; Very=
 briefly, some of us are interested in having a standardized
<br>&gt; function which does not incur an upfront memory allocation to stor=
e
<br>&gt; the callable target, instead opting for a compile time specified
<br>&gt; buffer (stack allocated). This has been quite useful in several lo=
w
<br>&gt; latency domains such as gaming and electronic trading. In other wo=
rds,
<br>&gt; a drop-in replacement for std::function, where all data is on the
<br>&gt; stack.
<br>
<br>Isn&#39;t this already possible by using today&#39;s `std::function` wi=
th a
<br>custom allocator backed by a stack-based array? =C2=A0The only thing th=
is
<br>solution cannot easily do for you is checking statically that the buffe=
r
<br>is large enough but since the size of an object is a constant, a single
<br>unit test that passes control flow through the creation of the
<br>type-erased function object would give that assurance to you.
<br>
<br>`std::function` type-erases the allocator as well but I&#39;d be very
<br>disappointed if this would mean a heap allocation for a simple stack
<br>allocator with a state as small as two pointers. =C2=A0I&#39;m not able=
 to point
<br>to a source that confirms this, though.
<br>
<br>It&#39;s likely that if you care about `std::function` not calling `mal=
loc`,
<br>you probably care about small (but still too large for SSO) and
<br>short-lived strings and similar stuff, too. =C2=A0Custom allocators pro=
vide a
<br>uniform interface to this without having to re-implement each type as a
<br>stack-based alternative.
<br>
<br>Am I missing something essential that your proposed
<br>`std::inplace_function` can do in addition?
<br></blockquote><div><br></div><div>The allocator support in std::function=
 has been zapped as of three weeks ago.=C2=A0</div><div><br></div><div>Also=
, passing such a thing around is trickier since the array&#39;s lifetime is=
 independent of the std::function.</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/28284ab7-1046-4631-bb4c-f755ce96c2e3%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/28284ab7-1046-4631-bb4c-f755ce96c2e3=
%40isocpp.org</a>.<br />

------=_Part_24_856620174.1468475912469--

------=_Part_23_1223753247.1468475912469--

.

> I'm not clear as to what you mean here. Consider this:
>
> std::function<void()> a_func()
> {
>   return []{};
> }
>
> What would the "stack-based array" equivalent look like? Would it look
> as reasonable as this? Would it be able to use that nifty guaranteed
> elision stuff we'll be getting?

I think you'd have to pass the allocator as an argument to `a_func`.  It
would be more involved than your snippet but probably still
"reasonable".  Anyway, this...

> The allocator support in std::function has been zapped as of three
> weeks ago.

makes my entire point obsolete, of course.  The only remaining feedback
I can provide then is to suggest you add a quick note to the motivation
of the proposal that explains this.  I was somehow irritated that the
word "allocator" didn't appear a single time in a paper about memory
allocation.  If allocator support was removed for good reasons and the
proposed approach is considered a superior replacement, mentioning this
explicitly might help the uninvolved reader.

--
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/87poqgyux3.fsf%40gmail.com.

.

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

Could you have your paper discuss the difference vs LLVM's function_ref<> (
http://llvm.org/viewvc/llvm-project/llvm/trunk/include/llvm/ADT/STLExtras.h?revision=273520&view=markup#l62)
and explain your view (whatever it is) over which set of these possible
function abstractions we should put in the standard?

Thanks,
Jeffrey

On Wed, Jul 13, 2016 at 3:47 PM, Carl Cook <carl.cook@gmail.com> wrote:

> Hi all,
>
> This is a cross posting from the SG14 reflector, regarding a draft
> proposal some of us are working on.
>
> Very briefly, some of us are interested in having a standardized function
> which does not incur an upfront memory allocation to store the callable
> target, instead opting for a compile time specified buffer (stack
> allocated). This has been quite useful in several low latency domains such
> as gaming and electronic trading. In other words, a drop-in replacement for
> std::function, where all data is on the stack.
>
> The original post is here:
> https://groups.google.com/a/isocpp.org/d/topic/sg14/1Sw_qEdIYes/discussion
>
> The resultant draft proposal is here:
> https://github.com/WG21-SG14/SG14/blob/master/Docs/Proposals/NonAllocatingStandardFunction.pdf
>
>
> Please feel free to comment here or in the SG14 reflector. This is still
> very much in the draft stage, and all feedback is appreciated. The
> reference implementation is still a work in progress (
> https://github.com/WG21-SG14/SG14/blob/master/SG14/inplace_function.h).
>
> Many thanks,
> Carl
>
> --
> 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/e00db911-40f5-4c11-a4b8-32bba77aa0a5%40isocpp.org
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/e00db911-40f5-4c11-a4b8-32bba77aa0a5%40isocpp.org?utm_medium=email&utm_source=footer>
> .
>

--
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/CANh-dXnpUNf2O5NTj213K1Jfmhge1%3Deit6%2BSistzYWZj%2B5CkNg%40mail.gmail.com.

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

<div dir=3D"ltr">Could you have your paper discuss the difference vs LLVM&#=
39;s function_ref&lt;&gt; (<a href=3D"http://llvm.org/viewvc/llvm-project/l=
lvm/trunk/include/llvm/ADT/STLExtras.h?revision=3D273520&amp;view=3Dmarkup#=
l62">http://llvm.org/viewvc/llvm-project/llvm/trunk/include/llvm/ADT/STLExt=
ras.h?revision=3D273520&amp;view=3Dmarkup#l62</a>) and explain your view (w=
hatever it is) over which set of these possible function abstractions we sh=
ould put in the standard?<div><br></div><div>Thanks,</div><div>Jeffrey</div=
></div><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">On Wed, Ju=
l 13, 2016 at 3:47 PM, Carl Cook <span dir=3D"ltr">&lt;<a href=3D"mailto:ca=
rl.cook@gmail.com" target=3D"_blank">carl.cook@gmail.com</a>&gt;</span> wro=
te:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-=
left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">Hi all,<div><br></di=
v><div>This is a cross posting from the SG14 reflector, regarding a draft p=
roposal some of us are working on.</div><div><br></div><div>Very briefly, s=
ome of us are interested in having a standardized function which does not i=
ncur an upfront memory allocation to store the callable target, instead opt=
ing for a compile time specified buffer (stack allocated). This has been qu=
ite useful in several low latency domains such as gaming and electronic tra=
ding. In other words, a drop-in replacement for std::function, where all da=
ta is on the stack.<br></div><div><br></div><div>The original post is here:=
=C2=A0<a href=3D"https://groups.google.com/a/isocpp.org/d/topic/sg14/1Sw_qE=
dIYes/discussion" target=3D"_blank">https://groups.google.com/a/isocpp.org/=
d/topic/sg14/1Sw_qEdIYes/discussion</a></div><div><br></div><div>The result=
ant draft proposal is here:=C2=A0<a href=3D"https://github.com/WG21-SG14/SG=
14/blob/master/Docs/Proposals/NonAllocatingStandardFunction.pdf" target=3D"=
_blank">https://github.com/WG21-SG14/SG14/blob/master/Docs/Proposals/NonAll=
ocatingStandardFunction.pdf</a>=C2=A0</div><div><br></div><div>Please feel =
free to comment here or in the SG14 reflector. This is still very much in t=
he draft stage, and all feedback is appreciated. The reference implementati=
on is still a work in progress (<a href=3D"https://github.com/WG21-SG14/SG1=
4/blob/master/SG14/inplace_function.h" target=3D"_blank">https://github.com=
/WG21-SG14/SG14/blob/master/SG14/inplace_function.h</a>).</div><div><br></d=
iv><div>Many thanks,</div><div>Carl</div><span class=3D"HOEnZb"><font color=
=3D"#888888"><div><br></div></font></span></div><span class=3D"HOEnZb"><fon=
t color=3D"#888888">

<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" target=3D"_=
blank">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">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/e00db911-40f5-4c11-a4b8-32bba77aa0a5%=
40isocpp.org?utm_medium=3Demail&amp;utm_source=3Dfooter" target=3D"_blank">=
https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/e00db911-40f5-=
4c11-a4b8-32bba77aa0a5%40isocpp.org</a>.<br>
</font></span></blockquote></div><br></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/CANh-dXnpUNf2O5NTj213K1Jfmhge1%3Deit6=
%2BSistzYWZj%2B5CkNg%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfoote=
r">https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CANh-dXnpUN=
f2O5NTj213K1Jfmhge1%3Deit6%2BSistzYWZj%2B5CkNg%40mail.gmail.com</a>.<br />

--001a11402c7ab044da05379d1c67--

.

------=_Part_1130_1635151240.1468536992777
Content-Type: multipart/alternative;
 boundary="----=_Part_1131_2098187099.1468536992778"

------=_Part_1131_2098187099.1468536992778
Content-Type: text/plain; charset=UTF-8

Hi all,

Thanks very much for the feedback so far, this is exactly what I was
looking for.

Below are my responses to the questions raised. Please let me know if I
haven't answered concisely enough, or have misunderstood the comments.

   - Is this too specialized for the standard library? Should this be in a
   TR/boost/extension only?
      - This is the most important comment in my opinion, and the driver
      for this proposal - to determine the level of support
      - Possibly it should be kept out of the standard. Here we are talking
      about introducting a whole new type, plus optionally specifying buffer
      sizes/alignment, just to save an allocation
      - On the flip side, it's actually more than an allocation. It's cache
      locality, potential to prefetch, deterministic performance, etc
      - This leads on to a bigger question - should low latency/high
      performance be a concern of the standard library?
         - I would argue yes, as industries such as finance/games/image
         processing/aerospace represent a large set of C++ users, and low latency
         requirements are a reality


   - How to determine the correct buffer size, at all times?
      - You can't. For that, fall back to std::function
      - In reality, inplace_function will only be used in specialized
      cases, and for that you will have a good idea of the size of the callable
      object
         - If your size is too conservative, the static assert will tell
         you what size you should have used
      - Also, from experience, the implementation's default size is fine
      90% of the time


   - Why not consider a custom allocator?
      - Primarily, for performance (keeping the allocated memory together
      with the function object itself is important, for example)
      - A secondary concern is simplicity (another template argument
      introduces more complexity in terms of copy construction, assignment, etc)
         - That was a good point about the allocator memory outliving the
         function as well
      - Another concern is giving the implementation freedom in terms of
      memory layout/alignment/type erasure/management function pointers, etc
      (custom allocators make this harder to acheive)
      - I'll add this discussion to the design considerations part of the
      spec


   - What's the difference between inplace_function and LLVM's function_ref?
      - Excellent point - I've not seen function_ref until today
         - One difference - an inplace_function can be stored/copied/moved,
         even for non-trivial callable objects (for function_ref you'd need a second
         step of converting this to a std::function before storing/copying)
         - Another difference - I am not convinced function_ref
         successfully captures closures correctly (at least in GCC on -O1 or above,
         it doesn't appear to capture out of scope variables by reference or copy)
      - Again, I'll expand on this and add this to the proposal (after
      taking a closer look at function_ref)


   - Why not publish this draft proposal on github.io?
      - I don't particularly like having to push updated pdfs into github
      either, but I think the best thing for me to do is rewrite the proposal in
      markdown
      - Incidentally, github renders pdfs fine for me (using
      chrome/chromeos)

Again, thanks very much for the comments so far. This helps improve the
proposal, even if it never makes it out of draft stage.

Please keep in mind that the primary goal of this proposal (at present) is
to measure the interest/response of such a mechanism. But I do note several
related proposals such as small/inplace vectors, inplace strings, inplace
any/variant - i.e. there seems to be a theme here.

Many thanks,
Carl

On Thursday, 14 July 2016 23:00:20 UTC+4, Jeffrey Yasskin wrote:
>
> Could you have your paper discuss the difference vs LLVM's function_ref<> (
> http://llvm.org/viewvc/llvm-project/llvm/trunk/include/llvm/ADT/STLExtras.h?revision=273520&view=markup#l62)
> and explain your view (whatever it is) over which set of these possible
> function abstractions we should put in the standard?
>
> Thanks,
> Jeffrey
>
> On Wed, Jul 13, 2016 at 3:47 PM, Carl Cook <carl...@gmail.com
> <javascript:>> wrote:
>
>> Hi all,
>>
>> This is a cross posting from the SG14 reflector, regarding a draft
>> proposal some of us are working on.
>>
>> Very briefly, some of us are interested in having a standardized function
>> which does not incur an upfront memory allocation to store the callable
>> target, instead opting for a compile time specified buffer (stack
>> allocated). This has been quite useful in several low latency domains such
>> as gaming and electronic trading. In other words, a drop-in replacement for
>> std::function, where all data is on the stack.
>>
>> The original post is here:
>> https://groups.google.com/a/isocpp.org/d/topic/sg14/1Sw_qEdIYes/discussion
>>
>> The resultant draft proposal is here:
>> https://github.com/WG21-SG14/SG14/blob/master/Docs/Proposals/NonAllocatingStandardFunction.pdf
>>
>>
>> Please feel free to comment here or in the SG14 reflector. This is still
>> very much in the draft stage, and all feedback is appreciated. The
>> reference implementation is still a work in progress (
>> https://github.com/WG21-SG14/SG14/blob/master/SG14/inplace_function.h).
>>
>> Many thanks,
>> Carl
>>
>> --
>> 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-proposal...@isocpp.org <javascript:>.
>> To post to this group, send email to std-pr...@isocpp.org <javascript:>.
>> To view this discussion on the web visit
>> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/e00db911-40f5-4c11-a4b8-32bba77aa0a5%40isocpp.org
>> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/e00db911-40f5-4c11-a4b8-32bba77aa0a5%40isocpp.org?utm_medium=email&utm_source=footer>
>> .
>>
>
>

--
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/ff1087cf-5777-47e9-8caa-d28136aae130%40isocpp.org.

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

<div dir=3D"ltr">Hi all,<div><br></div><div>Thanks very much for the feedba=
ck so far, this is exactly what I was looking for.</div><div><br></div><div=
>Below are my responses to the questions raised. Please let me know if I ha=
ven&#39;t answered concisely enough, or have misunderstood the comments.</d=
iv><div><ul><li>Is this too specialized for the standard library? Should th=
is be in a TR/boost/extension only?</li><ul><li>This is the most important =
comment in my opinion, and the driver for this proposal - to determine the =
level of support</li><li>Possibly it should be kept out of the standard. He=
re we are talking about introducting a whole new type, plus optionally spec=
ifying buffer sizes/alignment, just to save an allocation</li><li>On the fl=
ip side, it&#39;s actually more than an allocation. It&#39;s cache locality=
, potential to prefetch, deterministic performance, etc</li><li>This leads =
on to a bigger question - should low latency/high performance be a concern =
of the standard library?</li><ul><li>I would argue yes, as industries such =
as finance/games/image processing/aerospace represent a large set of C++ us=
ers, and low latency requirements are a reality</li></ul></ul></ul><ul><li>=
How to determine the correct buffer size, at all times?</li><ul><li>You can=
&#39;t. For that, fall back to std::function</li><li>In reality, inplace_fu=
nction will only be used in specialized cases, and for that you will have a=
 good idea of the size of the callable object</li><ul><li>If your size is t=
oo conservative, the static assert will tell you what size you should have =
used</li></ul><li>Also, from experience, the implementation&#39;s default s=
ize is fine 90% of the time</li></ul></ul><ul><li>Why not consider a custom=
 allocator?</li><ul><li>Primarily, for performance (keeping the allocated m=
emory together with the function object itself is important, for example)</=
li><li>A secondary concern is simplicity (another template argument introdu=
ces more complexity in terms of copy construction, assignment, etc)</li><ul=
><li>That was a good point about the allocator memory outliving the functio=
n as well</li></ul><li>Another concern is giving the implementation freedom=
 in terms of memory layout/alignment/type erasure/management function point=
ers, etc (custom allocators make this harder to acheive)</li><li>I&#39;ll a=
dd this discussion to the design considerations part of the spec</li></ul><=
/ul><ul><li>What&#39;s the difference between inplace_function and LLVM&#39=
;s function_ref?</li><ul><li>Excellent point - I&#39;ve not seen function_r=
ef until today</li><ul><li>One difference - an inplace_function can be stor=
ed/copied/moved, even for non-trivial callable objects (for function_ref yo=
u&#39;d need a second step of converting this to a std::function before sto=
ring/copying)</li><li>Another difference - I am not convinced function_ref =
successfully captures closures correctly (at least in GCC on -O1 or above, =
it doesn&#39;t appear to capture out of scope variables by reference or cop=
y)</li></ul><li>Again, I&#39;ll expand on this and add this to the proposal=
 (after taking a closer look at function_ref)</li></ul></ul><ul><li>Why not=
 publish this draft proposal on github.io?</li><ul><li>I don&#39;t particul=
arly like having to push updated pdfs into github either, but I think the b=
est thing for me to do is rewrite the proposal in markdown</li><li>Incident=
ally, github renders pdfs fine for me (using chrome/chromeos)</li></ul></ul=
><div><span style=3D"line-height: 17px;">Again, thanks very much for the co=
mments so far. This helps improve the proposal, even if it never makes it o=
ut of draft stage.</span></div><div><span style=3D"line-height: 17px;"><br>=
</span></div><div><span style=3D"line-height: 17px;">Please keep in mind th=
at the primary goal of this proposal (at present) is to measure the interes=
t/response of such a mechanism. But I do note several related proposals suc=
h as small/inplace vectors, inplace strings, inplace any/variant - i.e. the=
re seems to be a theme here.</span></div><div><span style=3D"line-height: 1=
7px;"><br></span></div><div><span style=3D"line-height: 17px;">Many thanks,=
</span></div><div><span style=3D"line-height: 17px;">Carl</span></div><div>=
<span style=3D"line-height: 17px;"><br></span></div>On Thursday, 14 July 20=
16 23:00:20 UTC+4, Jeffrey Yasskin  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">Could you have your paper discuss the differen=
ce vs LLVM&#39;s function_ref&lt;&gt; (<a href=3D"http://llvm.org/viewvc/ll=
vm-project/llvm/trunk/include/llvm/ADT/STLExtras.h?revision=3D273520&amp;vi=
ew=3Dmarkup#l62" target=3D"_blank" rel=3D"nofollow" onmousedown=3D"this.hre=
f=3D&#39;http://www.google.com/url?q\x3dhttp%3A%2F%2Fllvm.org%2Fviewvc%2Fll=
vm-project%2Fllvm%2Ftrunk%2Finclude%2Fllvm%2FADT%2FSTLExtras.h%3Frevision%3=
D273520%26view%3Dmarkup%23l62\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNG2VOa=
LfzbZPYQNoMs0NhJE53qHVw&#39;;return true;" onclick=3D"this.href=3D&#39;http=
://www.google.com/url?q\x3dhttp%3A%2F%2Fllvm.org%2Fviewvc%2Fllvm-project%2F=
llvm%2Ftrunk%2Finclude%2Fllvm%2FADT%2FSTLExtras.h%3Frevision%3D273520%26vie=
w%3Dmarkup%23l62\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNG2VOaLfzbZPYQNoMs0=
NhJE53qHVw&#39;;return true;">http://llvm.org/viewvc/llvm-<wbr>project/llvm=
/trunk/include/<wbr>llvm/ADT/STLExtras.h?revision=3D<wbr>273520&amp;view=3D=
markup#l62</a>) and explain your view (whatever it is) over which set of th=
ese possible function abstractions we should put in the standard?<div><br><=
/div><div>Thanks,</div><div>Jeffrey</div></div><div><br><div class=3D"gmail=
_quote">On Wed, Jul 13, 2016 at 3:47 PM, Carl Cook <span dir=3D"ltr">&lt;<a=
 href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"vZjw36hXCw=
AJ" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;javascript:&#39;;retur=
n true;" onclick=3D"this.href=3D&#39;javascript:&#39;;return true;">carl...=
@gmail.com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=
=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=
=3D"ltr">Hi all,<div><br></div><div>This is a cross posting from the SG14 r=
eflector, regarding a draft proposal some of us are working on.</div><div><=
br></div><div>Very briefly, some of us are interested in having a standardi=
zed function which does not incur an upfront memory allocation to store the=
 callable target, instead opting for a compile time specified buffer (stack=
 allocated). This has been quite useful in several low latency domains such=
 as gaming and electronic trading. In other words, a drop-in replacement fo=
r std::function, where all data is on the stack.<br></div><div><br></div><d=
iv>The original post is here:=C2=A0<a href=3D"https://groups.google.com/a/i=
socpp.org/d/topic/sg14/1Sw_qEdIYes/discussion" target=3D"_blank" rel=3D"nof=
ollow" onmousedown=3D"this.href=3D&#39;https://groups.google.com/a/isocpp.o=
rg/d/topic/sg14/1Sw_qEdIYes/discussion&#39;;return true;" onclick=3D"this.h=
ref=3D&#39;https://groups.google.com/a/isocpp.org/d/topic/sg14/1Sw_qEdIYes/=
discussion&#39;;return true;">https://groups.google.<wbr>com/a/isocpp.org/d=
/topic/sg14/<wbr>1Sw_qEdIYes/discussion</a></div><div><br></div><div>The re=
sultant draft proposal is here:=C2=A0<a href=3D"https://github.com/WG21-SG1=
4/SG14/blob/master/Docs/Proposals/NonAllocatingStandardFunction.pdf" target=
=3D"_blank" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;https://www.go=
ogle.com/url?q\x3dhttps%3A%2F%2Fgithub.com%2FWG21-SG14%2FSG14%2Fblob%2Fmast=
er%2FDocs%2FProposals%2FNonAllocatingStandardFunction.pdf\x26sa\x3dD\x26snt=
z\x3d1\x26usg\x3dAFQjCNH8L3ZxF9S9eAP8Pb8VADulY7Ri6g&#39;;return true;" oncl=
ick=3D"this.href=3D&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fgithu=
b.com%2FWG21-SG14%2FSG14%2Fblob%2Fmaster%2FDocs%2FProposals%2FNonAllocating=
StandardFunction.pdf\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNH8L3ZxF9S9eAP8=
Pb8VADulY7Ri6g&#39;;return true;">https://github.com/WG21-<wbr>SG14/SG14/bl=
ob/master/Docs/<wbr>Proposals/<wbr>NonAllocatingStandardFunction.<wbr>pdf</=
a>=C2=A0</div><div><br></div><div>Please feel free to comment here or in th=
e SG14 reflector. This is still very much in the draft stage, and all feedb=
ack is appreciated. The reference implementation is still a work in progres=
s (<a href=3D"https://github.com/WG21-SG14/SG14/blob/master/SG14/inplace_fu=
nction.h" target=3D"_blank" rel=3D"nofollow" onmousedown=3D"this.href=3D&#3=
9;https://www.google.com/url?q\x3dhttps%3A%2F%2Fgithub.com%2FWG21-SG14%2FSG=
14%2Fblob%2Fmaster%2FSG14%2Finplace_function.h\x26sa\x3dD\x26sntz\x3d1\x26u=
sg\x3dAFQjCNGWex35dzi6es2jTmGdKPw9asRYXQ&#39;;return true;" onclick=3D"this=
..href=3D&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fgithub.com%2FWG2=
1-SG14%2FSG14%2Fblob%2Fmaster%2FSG14%2Finplace_function.h\x26sa\x3dD\x26snt=
z\x3d1\x26usg\x3dAFQjCNGWex35dzi6es2jTmGdKPw9asRYXQ&#39;;return true;">http=
s://github.com/WG21-SG14/<wbr>SG14/blob/master/SG14/inplace_<wbr>function.h=
</a>).</div><div><br></div><div>Many thanks,</div><div>Carl</div><span><fon=
t color=3D"#888888"><div><br></div></font></span></div><span><font color=3D=
"#888888">

<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"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"=
vZjw36hXCwAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;javascript:&=
#39;;return true;" onclick=3D"this.href=3D&#39;javascript:&#39;;return true=
;">std-proposal...@<wbr>isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"javascript:" target=3D"_bla=
nk" gdf-obfuscated-mailto=3D"vZjw36hXCwAJ" rel=3D"nofollow" 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>.<br>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/e00db911-40f5-4c11-a4b8-32bba77aa0a5%=
40isocpp.org?utm_medium=3Demail&amp;utm_source=3Dfooter" target=3D"_blank" =
rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;https://groups.google.com/=
a/isocpp.org/d/msgid/std-proposals/e00db911-40f5-4c11-a4b8-32bba77aa0a5%40i=
socpp.org?utm_medium\x3demail\x26utm_source\x3dfooter&#39;;return true;" on=
click=3D"this.href=3D&#39;https://groups.google.com/a/isocpp.org/d/msgid/st=
d-proposals/e00db911-40f5-4c11-a4b8-32bba77aa0a5%40isocpp.org?utm_medium\x3=
demail\x26utm_source\x3dfooter&#39;;return true;">https://groups.google.com=
/a/<wbr>isocpp.org/d/msgid/std-<wbr>proposals/e00db911-40f5-4c11-<wbr>a4b8-=
32bba77aa0a5%40isocpp.org</a><wbr>.<br>
</font></span></blockquote></div><br></div>
</blockquote></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/ff1087cf-5777-47e9-8caa-d28136aae130%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/ff1087cf-5777-47e9-8caa-d28136aae130=
%40isocpp.org</a>.<br />

------=_Part_1131_2098187099.1468536992778--

------=_Part_1130_1635151240.1468536992777--

.

Here's my 2 cents:

On 15 July 2016 at 01:56, Carl Cook <carl.cook@gmail.com> wrote:
> Hi all,
>
> Thanks very much for the feedback so far, this is exactly what I was looking
> for.
>
> Below are my responses to the questions raised. Please let me know if I
> haven't answered concisely enough, or have misunderstood the comments.
>
> Is this too specialized for the standard library? Should this be in a
> TR/boost/extension only?
>
> This is the most important comment in my opinion, and the driver for this
> proposal - to determine the level of support
> Possibly it should be kept out of the standard. Here we are talking about
> introducting a whole new type, plus optionally specifying buffer
> sizes/alignment, just to save an allocation
> On the flip side, it's actually more than an allocation. It's cache
> locality, potential to prefetch, deterministic performance, etc
> This leads on to a bigger question - should low latency/high performance be
> a concern of the standard library?
>
> I would argue yes, as industries such as finance/games/image
> processing/aerospace represent a large set of C++ users, and low latency
> requirements are a reality

It's also not just about latency. There are environments where
subsystems have fixed pools, and not
being able to exactly control what and how much gets allocated and
from where is unacceptable.
Controlling it with an in-place buffer works in quite many cases.

>
> How to determine the correct buffer size, at all times?
>
> You can't. For that, fall back to std::function
> In reality, inplace_function will only be used in specialized cases, and for
> that you will have a good idea of the size of the callable object
>
> If your size is too conservative, the static assert will tell you what size
> you should have used
>
> Also, from experience, the implementation's default size is fine 90% of the
> time

Fantastic, that solves quite many practical problems I've seen in this
area. Fail to compile rather
than fail to allocate at run-time.

>
> Why not consider a custom allocator?

Because that's a much more complex solution than a fixed in-place buffer. ;)

--
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/CAFk2RUY%2B8fSwVvw1SJOgvF52AcX9MWZm9RKzgEQN7fmnCNDhaw%40mail.gmail.com.

.

--94eb2c0837a64baff50537a1ccfc
Content-Type: text/plain; charset=UTF-8

On Thu, Jul 14, 2016 at 3:56 PM, Carl Cook <carl.cook@gmail.com> wrote:

> Hi all,
>
> Thanks very much for the feedback so far, this is exactly what I was
> looking for.
>
> Below are my responses to the questions raised. Please let me know if I
> haven't answered concisely enough, or have misunderstood the comments.
>
>    - Is this too specialized for the standard library? Should this be in
>    a TR/boost/extension only?
>       - This is the most important comment in my opinion, and the driver
>       for this proposal - to determine the level of support
>       - Possibly it should be kept out of the standard. Here we are
>       talking about introducting a whole new type, plus optionally specifying
>       buffer sizes/alignment, just to save an allocation
>       - On the flip side, it's actually more than an allocation. It's
>       cache locality, potential to prefetch, deterministic performance, etc
>       - This leads on to a bigger question - should low latency/high
>       performance be a concern of the standard library?
>          - I would argue yes, as industries such as finance/games/image
>          processing/aerospace represent a large set of C++ users, and low latency
>          requirements are a reality
>
>
>    - How to determine the correct buffer size, at all times?
>       - You can't. For that, fall back to std::function
>       - In reality, inplace_function will only be used in specialized
>       cases, and for that you will have a good idea of the size of the callable
>       object
>          - If your size is too conservative, the static assert will tell
>          you what size you should have used
>       - Also, from experience, the implementation's default size is fine
>       90% of the time
>
>
>    - Why not consider a custom allocator?
>       - Primarily, for performance (keeping the allocated memory together
>       with the function object itself is important, for example)
>       - A secondary concern is simplicity (another template argument
>       introduces more complexity in terms of copy construction, assignment, etc)
>          - That was a good point about the allocator memory outliving the
>          function as well
>       - Another concern is giving the implementation freedom in terms of
>       memory layout/alignment/type erasure/management function pointers, etc
>       (custom allocators make this harder to acheive)
>       - I'll add this discussion to the design considerations part of the
>       spec
>
>
>    - What's the difference between inplace_function and LLVM's
>    function_ref?
>       - Excellent point - I've not seen function_ref until today
>          - One difference - an inplace_function can be
>          stored/copied/moved, even for non-trivial callable objects (for
>          function_ref you'd need a second step of converting this to a std::function
>          before storing/copying)
>          - Another difference - I am not convinced function_ref
>          successfully captures closures correctly (at least in GCC on -O1 or above,
>          it doesn't appear to capture out of scope variables by reference or copy)
>
> llvm::function_ref doesn't capture anything, and is not supposed to --
it's a *non-owning* handle to a callable that outlives the handle.
(llvm::function_ref is to std::function as std::string_view is to
std::string.) This is a feature and a design goal of llvm::function_ref,
but I think it means it's addressing a fundamentally different problem than
the one you're tackling here (which seems to be essentially, "let me
control the size and alignment in std::function's small function
optimization")

>
>    - Again, I'll expand on this and add this to the proposal (after
>       taking a closer look at function_ref)
>
>
>    - Why not publish this draft proposal on github.io?
>       - I don't particularly like having to push updated pdfs into github
>       either, but I think the best thing for me to do is rewrite the proposal in
>       markdown
>       - Incidentally, github renders pdfs fine for me (using
>       chrome/chromeos)
>
> Again, thanks very much for the comments so far. This helps improve the
> proposal, even if it never makes it out of draft stage.
>
> Please keep in mind that the primary goal of this proposal (at present) is
> to measure the interest/response of such a mechanism. But I do note several
> related proposals such as small/inplace vectors, inplace strings, inplace
> any/variant - i.e. there seems to be a theme here.
>
> Many thanks,
> Carl
>
> On Thursday, 14 July 2016 23:00:20 UTC+4, Jeffrey Yasskin wrote:
>>
>> Could you have your paper discuss the difference vs LLVM's function_ref<>
>> (
>> http://llvm.org/viewvc/llvm-project/llvm/trunk/include/llvm/ADT/STLExtras.h?revision=273520&view=markup#l62)
>> and explain your view (whatever it is) over which set of these possible
>> function abstractions we should put in the standard?
>>
>> Thanks,
>> Jeffrey
>>
>> On Wed, Jul 13, 2016 at 3:47 PM, Carl Cook <carl...@gmail.com> wrote:
>>
>>> Hi all,
>>>
>>> This is a cross posting from the SG14 reflector, regarding a draft
>>> proposal some of us are working on.
>>>
>>> Very briefly, some of us are interested in having a standardized
>>> function which does not incur an upfront memory allocation to store the
>>> callable target, instead opting for a compile time specified buffer (stack
>>> allocated). This has been quite useful in several low latency domains such
>>> as gaming and electronic trading. In other words, a drop-in replacement for
>>> std::function, where all data is on the stack.
>>>
>>> The original post is here:
>>> https://groups.google.com/a/isocpp.org/d/topic/sg14/1Sw_qEdIYes/discussion
>>>
>>> The resultant draft proposal is here:
>>> https://github.com/WG21-SG14/SG14/blob/master/Docs/Proposals/NonAllocatingStandardFunction.pdf
>>>
>>>
>>> Please feel free to comment here or in the SG14 reflector. This is still
>>> very much in the draft stage, and all feedback is appreciated. The
>>> reference implementation is still a work in progress (
>>> https://github.com/WG21-SG14/SG14/blob/master/SG14/inplace_function.h).
>>>
>>> Many thanks,
>>> Carl
>>>
>>> --
>>> 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-proposal...@isocpp.org.
>>> To post to this group, send email to std-pr...@isocpp.org.
>>> To view this discussion on the web visit
>>> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/e00db911-40f5-4c11-a4b8-32bba77aa0a5%40isocpp.org
>>> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/e00db911-40f5-4c11-a4b8-32bba77aa0a5%40isocpp.org?utm_medium=email&utm_source=footer>
>>> .
>>>
>>
>> --
> 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/ff1087cf-5777-47e9-8caa-d28136aae130%40isocpp.org
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/ff1087cf-5777-47e9-8caa-d28136aae130%40isocpp.org?utm_medium=email&utm_source=footer>
> .
>

--
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/CAOfiQqn31H_Mfkxx3yty1%3Dwqu50JnpcSv25uLP3DNDTb5E8WYQ%40mail.gmail.com.

--94eb2c0837a64baff50537a1ccfc
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 14, 2016 at 3:56 PM, Carl Cook <span dir=3D"ltr">&lt;<a href=3D"mai=
lto:carl.cook@gmail.com" target=3D"_blank">carl.cook@gmail.com</a>&gt;</spa=
n> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;b=
order-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">Hi all,<div><b=
r></div><div>Thanks very much for the feedback so far, this is exactly what=
 I was looking for.</div><div><br></div><div>Below are my responses to the =
questions raised. Please let me know if I haven&#39;t answered concisely en=
ough, or have misunderstood the comments.</div><div><ul><li>Is this too spe=
cialized for the standard library? Should this be in a TR/boost/extension o=
nly?</li><ul><li>This is the most important comment in my opinion, and the =
driver for this proposal - to determine the level of support</li><li>Possib=
ly it should be kept out of the standard. Here we are talking about introdu=
cting a whole new type, plus optionally specifying buffer sizes/alignment, =
just to save an allocation</li><li>On the flip side, it&#39;s actually more=
 than an allocation. It&#39;s cache locality, potential to prefetch, determ=
inistic performance, etc</li><li>This leads on to a bigger question - shoul=
d low latency/high performance be a concern of the standard library?</li><u=
l><li>I would argue yes, as industries such as finance/games/image processi=
ng/aerospace represent a large set of C++ users, and low latency requiremen=
ts are a reality</li></ul></ul></ul><ul><li>How to determine the correct bu=
ffer size, at all times?</li><ul><li>You can&#39;t. For that, fall back to =
std::function</li><li>In reality, inplace_function will only be used in spe=
cialized cases, and for that you will have a good idea of the size of the c=
allable object</li><ul><li>If your size is too conservative, the static ass=
ert will tell you what size you should have used</li></ul><li>Also, from ex=
perience, the implementation&#39;s default size is fine 90% of the time</li=
></ul></ul><ul><li>Why not consider a custom allocator?</li><ul><li>Primari=
ly, for performance (keeping the allocated memory together with the functio=
n object itself is important, for example)</li><li>A secondary concern is s=
implicity (another template argument introduces more complexity in terms of=
 copy construction, assignment, etc)</li><ul><li>That was a good point abou=
t the allocator memory outliving the function as well</li></ul><li>Another =
concern is giving the implementation freedom in terms of memory layout/alig=
nment/type erasure/management function pointers, etc (custom allocators mak=
e this harder to acheive)</li><li>I&#39;ll add this discussion to the desig=
n considerations part of the spec</li></ul></ul><ul><li>What&#39;s the diff=
erence between inplace_function and LLVM&#39;s function_ref?</li><ul><li>Ex=
cellent point - I&#39;ve not seen function_ref until today</li><ul><li>One =
difference - an inplace_function can be stored/copied/moved, even for non-t=
rivial callable objects (for function_ref you&#39;d need a second step of c=
onverting this to a std::function before storing/copying)</li><li>Another d=
ifference - I am not convinced function_ref successfully captures closures =
correctly (at least in GCC on -O1 or above, it doesn&#39;t appear to captur=
e out of scope variables by reference or copy)</li></ul></ul></ul></div></d=
iv></blockquote><div>llvm::function_ref doesn&#39;t capture anything, and i=
s not supposed to -- it&#39;s a *non-owning* handle to a callable that outl=
ives the handle. (llvm::function_ref is to std::function as std::string_vie=
w is to std::string.) This is a feature and a design goal of llvm::function=
_ref, but I think it means it&#39;s addressing a fundamentally different pr=
oblem than the one you&#39;re tackling here (which seems to be essentially,=
 &quot;let me control the size and alignment in std::function&#39;s small f=
unction optimization&quot;)<br></div><blockquote class=3D"gmail_quote" styl=
e=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div di=
r=3D"ltr"><div><ul><ul><li>Again, I&#39;ll expand on this and add this to t=
he proposal (after taking a closer look at function_ref)</li></ul></ul><ul>=
<li>Why not publish this draft proposal on <a href=3D"http://github.io" tar=
get=3D"_blank">github.io</a>?</li><ul><li>I don&#39;t particularly like hav=
ing to push updated pdfs into github either, but I think the best thing for=
 me to do is rewrite the proposal in markdown</li><li>Incidentally, github =
renders pdfs fine for me (using chrome/chromeos)</li></ul></ul><div><span s=
tyle=3D"line-height:17px">Again, thanks very much for the comments so far. =
This helps improve the proposal, even if it never makes it out of draft sta=
ge.</span></div><div><span style=3D"line-height:17px"><br></span></div><div=
><span style=3D"line-height:17px">Please keep in mind that the primary goal=
 of this proposal (at present) is to measure the interest/response of such =
a mechanism. But I do note several related proposals such as small/inplace =
vectors, inplace strings, inplace any/variant - i.e. there seems to be a th=
eme here.</span></div><div><span style=3D"line-height:17px"><br></span></di=
v><div><span style=3D"line-height:17px">Many thanks,</span></div><div><span=
 style=3D"line-height:17px">Carl</span></div><span class=3D""><div><span st=
yle=3D"line-height:17px"><br></span></div>On Thursday, 14 July 2016 23:00:2=
0 UTC+4, Jeffrey Yasskin  wrote:</span><blockquote class=3D"gmail_quote" st=
yle=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1=
ex"><span class=3D""><div dir=3D"ltr">Could you have your paper discuss the=
 difference vs LLVM&#39;s function_ref&lt;&gt; (<a href=3D"http://llvm.org/=
viewvc/llvm-project/llvm/trunk/include/llvm/ADT/STLExtras.h?revision=3D2735=
20&amp;view=3Dmarkup#l62" rel=3D"nofollow" target=3D"_blank">http://llvm.or=
g/viewvc/llvm-project/llvm/trunk/include/llvm/ADT/STLExtras.h?revision=3D27=
3520&amp;view=3Dmarkup#l62</a>) and explain your view (whatever it is) over=
 which set of these possible function abstractions we should put in the sta=
ndard?<div><br></div><div>Thanks,</div><div>Jeffrey</div></div></span><div>=
<br><div class=3D"gmail_quote"><span class=3D"">On Wed, Jul 13, 2016 at 3:4=
7 PM, Carl Cook <span dir=3D"ltr">&lt;<a rel=3D"nofollow">carl...@gmail.com=
</a>&gt;</span> wrote:<br></span><blockquote class=3D"gmail_quote" style=3D=
"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=
=3D""><div dir=3D"ltr">Hi all,<div><br></div><div>This is a cross posting f=
rom the SG14 reflector, regarding a draft proposal some of us are working o=
n.</div><div><br></div><div>Very briefly, some of us are interested in havi=
ng a standardized function which does not incur an upfront memory allocatio=
n to store the callable target, instead opting for a compile time specified=
 buffer (stack allocated). This has been quite useful in several low latenc=
y domains such as gaming and electronic trading. In other words, a drop-in =
replacement for std::function, where all data is on the stack.<br></div><di=
v><br></div><div>The original post is here:=C2=A0<a href=3D"https://groups.=
google.com/a/isocpp.org/d/topic/sg14/1Sw_qEdIYes/discussion" rel=3D"nofollo=
w" target=3D"_blank">https://groups.google.com/a/isocpp.org/d/topic/sg14/1S=
w_qEdIYes/discussion</a></div><div><br></div><div>The resultant draft propo=
sal is here:=C2=A0<a href=3D"https://github.com/WG21-SG14/SG14/blob/master/=
Docs/Proposals/NonAllocatingStandardFunction.pdf" rel=3D"nofollow" target=
=3D"_blank">https://github.com/WG21-SG14/SG14/blob/master/Docs/Proposals/No=
nAllocatingStandardFunction.pdf</a>=C2=A0</div><div><br></div><div>Please f=
eel free to comment here or in the SG14 reflector. This is still very much =
in the draft stage, and all feedback is appreciated. The reference implemen=
tation is still a work in progress (<a href=3D"https://github.com/WG21-SG14=
/SG14/blob/master/SG14/inplace_function.h" rel=3D"nofollow" target=3D"_blan=
k">https://github.com/WG21-SG14/SG14/blob/master/SG14/inplace_function.h</a=
>).</div><div><br></div><div>Many thanks,</div><div>Carl</div><span><font c=
olor=3D"#888888"><div><br></div></font></span></div></span><span><font colo=
r=3D"#888888"><span class=3D"">

<p></p>

-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br></span>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a rel=3D"nofollow">std-proposal...@isocpp.org</a>.<br>
To post to this group, send email to <a rel=3D"nofollow">std-pr...@isocpp.o=
rg</a>.<span class=3D""><br>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/e00db911-40f5-4c11-a4b8-32bba77aa0a5%=
40isocpp.org?utm_medium=3Demail&amp;utm_source=3Dfooter" rel=3D"nofollow" t=
arget=3D"_blank">https://groups.google.com/a/isocpp.org/d/msgid/std-proposa=
ls/e00db911-40f5-4c11-a4b8-32bba77aa0a5%40isocpp.org</a>.<br>
</span></font></span></blockquote></div><br></div>
</blockquote></div></div><span class=3D"">

<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" target=3D"_=
blank">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br></span>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/ff1087cf-5777-47e9-8caa-d28136aae130%=
40isocpp.org?utm_medium=3Demail&amp;utm_source=3Dfooter" target=3D"_blank">=
https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/ff1087cf-5777-=
47e9-8caa-d28136aae130%40isocpp.org</a>.<br>
</blockquote></div><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/CAOfiQqn31H_Mfkxx3yty1%3Dwqu50JnpcSv2=
5uLP3DNDTb5E8WYQ%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAOfiQqn31H_Mfk=
xx3yty1%3Dwqu50JnpcSv25uLP3DNDTb5E8WYQ%40mail.gmail.com</a>.<br />

--94eb2c0837a64baff50537a1ccfc--

.

------=_Part_1078_887351346.1468551469902
Content-Type: multipart/alternative;
 boundary="----=_Part_1079_155533886.1468551469903"

------=_Part_1079_155533886.1468551469903
Content-Type: text/plain; charset=UTF-8

On Thursday, July 14, 2016 at 6:56:33 PM UTC-4, Carl Cook wrote:
>
> Hi all,
>
> Thanks very much for the feedback so far, this is exactly what I was
> looking for.
>
> Below are my responses to the questions raised. Please let me know if I
> haven't answered concisely enough, or have misunderstood the comments.
>
>    - Is this too specialized for the standard library? Should this be in
>    a TR/boost/extension only?
>       - This is the most important comment in my opinion, and the driver
>       for this proposal - to determine the level of support
>       - Possibly it should be kept out of the standard. Here we are
>       talking about introducting a whole new type, plus optionally specifying
>       buffer sizes/alignment, just to save an allocation
>       - On the flip side, it's actually more than an allocation. It's
>       cache locality, potential to prefetch, deterministic performance, etc
>       - This leads on to a bigger question - should low latency/high
>       performance be a concern of the standard library?
>          - I would argue yes, as industries such as finance/games/image
>          processing/aerospace represent a large set of C++ users, and low latency
>          requirements are a reality
>
> It's not a question of "should the standard library care about
high-performance code". It's a question of "how many high-performance
corner cases should be in the standard library?" You can keep adding stuff
to cover corner cases ad infinitum. At some point, you have to draw a line.

Remember: we are talking about a type which, in the very next section, you
admit "will only be used in specialized cases". To me, the standard library
should be for tools that are of general use.

You need a shared ownership pointer that can work with *anything*? We've
got that. But if the atomic nature of the reference count is a performance
problem for you, or if you really don't like the added allocation overhead
of the control block and want it to be intrusive, you'll have to look
elsewhere for a tool that services that need. You need a string type with
some basic-though-not-very-good string functionality? We've got that. But
if you need a string that has a guaranteed small size, or a specific small
size, or just a fixed maximum size period, that's something you need to
make for yourself.

That's why I like the idea of having a dedicated TS specifically for these
types of things. I'd love to see a TS full of `small_vector`,
`small_basic_string`, `inplace_function`, and so forth (but not
`flat_set/map`. Those *need to be* in the standard library). Please don't
look on TS's as some kind of ghetto for things that are not really
standard. Yes, they really are standard, they really are supplied by
compiler vendors, and they really are available.

They're just not part of the C++ standard library.

Similarly, I like the idea of the 2D graphics proposal, and maybe the input
proposals and so forth. But I don't think it is appropriate for the
standard library.

>
>    - How to determine the correct buffer size, at all times?
>       - You can't. For that, fall back to std::function
>
> This actually brings up a small technical deficiency with the current
proposal: no interop with `std::function`. Well, besides the obvious fact
that `inplace_function` is a callable and you could therefore shove one
into a `function` and vice-versa.

We ought to be able to convert between the two without creating overhead.
That is, this:

inplace_function<...> f(a_functor);
std::function<...> g = f;

Should not take up additional storage or function call overhead compared to:

std::function<...> g(a_functor);

At the very least, we should be able to go from `inplace_function` to
`std::function`. Preferably with move support, if possible. Obviously you
can't move the storage in the `inplace_function`, but you can at least move
the object being stored if it contains a `unique_ptr` or something.

Please keep in mind that the primary goal of this proposal (at present) is
> to measure the interest/response of such a mechanism. But I do note several
> related proposals such as small/inplace vectors, inplace strings, inplace
> any/variant - i.e. there seems to be a theme here.
>

Themes are TS material ;) Like networking or filesystems.

--
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/e725d932-5fbd-4ac9-b707-66ab6e02a413%40isocpp.org.

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

<div dir=3D"ltr">On Thursday, July 14, 2016 at 6:56:33 PM UTC-4, Carl Cook =
wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8=
ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr">Hi all,=
<div><br></div><div>Thanks very much for the feedback so far, this is exact=
ly what I was looking for.</div><div><br></div><div>Below are my responses =
to the questions raised. Please let me know if I haven&#39;t answered conci=
sely enough, or have misunderstood the comments.</div><div><ul><li>Is this =
too specialized for the standard library? Should this be in a TR/boost/exte=
nsion only?</li><ul><li>This is the most important comment in my opinion, a=
nd the driver for this proposal - to determine the level of support</li><li=
>Possibly it should be kept out of the standard. Here we are talking about =
introducting a whole new type, plus optionally specifying buffer sizes/alig=
nment, just to save an allocation</li><li>On the flip side, it&#39;s actual=
ly more than an allocation. It&#39;s cache locality, potential to prefetch,=
 deterministic performance, etc</li><li>This leads on to a bigger question =
- should low latency/high performance be a concern of the standard library?=
</li><ul><li>I would argue yes, as industries such as finance/games/image p=
rocessing/aerospace represent a large set of C++ users, and low latency req=
uirements are a reality</li></ul></ul></ul></div></div></blockquote><div>It=
&#39;s not a question of &quot;should the standard library care about high-=
performance code&quot;. It&#39;s a question of &quot;how many high-performa=
nce corner cases should be in the standard library?&quot; You can keep addi=
ng stuff to cover corner cases ad infinitum. At some point, you have to dra=
w a line.<br><br>Remember: we are talking about a type which, in the very n=
ext section, you admit &quot;will only be used in specialized cases&quot;. =
To me, the standard library should be for tools that are of general use.<br=
><br>You need a shared ownership pointer that can work with <i>anything</i>=
? We&#39;ve got that. But if the atomic nature of the reference count is a =
performance problem for you, or if you really don&#39;t like the added allo=
cation overhead of the control block and want it to be intrusive, you&#39;l=
l have to look elsewhere for a tool that services that need. You need a str=
ing type with some basic-though-not-very-good string functionality? We&#39;=
ve got that. But if you need a string that has a guaranteed small size, or =
a specific small size, or just a fixed maximum size period, that&#39;s some=
thing you need to make for yourself.<br><br>That&#39;s why I like the idea =
of having a dedicated TS specifically for these types of things. I&#39;d lo=
ve to see a TS full of `small_vector`, `small_basic_string`, `inplace_funct=
ion`, and so forth (but not `flat_set/map`. Those <i>need to be</i> in the =
standard library). Please don&#39;t look on TS&#39;s as some kind of ghetto=
 for things that are not really standard. Yes, they really are standard, th=
ey really are supplied by compiler vendors, and they really are available.<=
br><br>They&#39;re just not part of the C++ standard library.<br><br>Simila=
rly, I like the idea of the 2D graphics proposal, and maybe the input propo=
sals and so forth. But I don&#39;t think it is appropriate for the standard=
 library.<br></div><blockquote class=3D"gmail_quote" style=3D"margin: 0;mar=
gin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D=
"ltr"><div><ul><li>How to determine the correct buffer size, at all times?<=
/li><ul><li>You can&#39;t. For that, fall back to std::function</li></ul></=
ul></div></div></blockquote><div>This actually brings up a small technical =
deficiency with the current proposal: no interop with `std::function`. Well=
, besides the obvious fact that `inplace_function` is a callable and you co=
uld therefore shove one into a `function` and vice-versa.<br><br>We ought t=
o be able to convert between the two without creating overhead. That is, th=
is:<br><br><div class=3D"prettyprint" style=3D"background-color: rgb(250, 2=
50, 250); border-color: rgb(187, 187, 187); border-style: solid; border-wid=
th: 1px; word-wrap: break-word;"><code class=3D"prettyprint"><div class=3D"=
subprettyprint"><span style=3D"color: #000;" class=3D"styled-by-prettify">i=
nplace_function</span><span style=3D"color: #660;" class=3D"styled-by-prett=
ify">&lt;...&gt;</span><span style=3D"color: #000;" class=3D"styled-by-pret=
tify"> f</span><span style=3D"color: #660;" class=3D"styled-by-prettify">(<=
/span><span style=3D"color: #000;" class=3D"styled-by-prettify">a_functor</=
span><span style=3D"color: #660;" class=3D"styled-by-prettify">);</span><sp=
an style=3D"color: #000;" class=3D"styled-by-prettify"><br>std</span><span =
style=3D"color: #660;" class=3D"styled-by-prettify">::</span><span style=3D=
"color: #008;" class=3D"styled-by-prettify">function</span><span style=3D"c=
olor: #660;" class=3D"styled-by-prettify">&lt;...&gt;</span><span style=3D"=
color: #000;" class=3D"styled-by-prettify"> g </span><span style=3D"color: =
#660;" class=3D"styled-by-prettify">=3D</span><span style=3D"color: #000;" =
class=3D"styled-by-prettify"> f</span><span style=3D"color: #660;" class=3D=
"styled-by-prettify">;</span></div></code></div><br>Should not take up addi=
tional storage or function call overhead compared to:<br><br><div class=3D"=
prettyprint" style=3D"background-color: rgb(250, 250, 250); border-color: r=
gb(187, 187, 187); border-style: solid; border-width: 1px; word-wrap: break=
-word;"><code class=3D"prettyprint"><div class=3D"subprettyprint"><span sty=
le=3D"color: #000;" class=3D"styled-by-prettify">std</span><span style=3D"c=
olor: #660;" class=3D"styled-by-prettify">::</span><span style=3D"color: #0=
08;" class=3D"styled-by-prettify">function</span><span style=3D"color: #660=
;" class=3D"styled-by-prettify">&lt;...&gt;</span><span style=3D"color: #00=
0;" class=3D"styled-by-prettify"> g</span><span style=3D"color: #660;" clas=
s=3D"styled-by-prettify">(</span><span style=3D"color: #000;" class=3D"styl=
ed-by-prettify">a_functor</span><span style=3D"color: #660;" class=3D"style=
d-by-prettify">);</span></div></code></div><br>At the very least, we should=
 be able to go from `inplace_function` to `std::function`. Preferably with =
move support, if possible. Obviously you can&#39;t move the storage in the =
`inplace_function`, but you can at least move the object being stored if it=
 contains a `unique_ptr` or something.<br><br></div><blockquote class=3D"gm=
ail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc soli=
d;padding-left: 1ex;"><div dir=3D"ltr"><div><div><span style=3D"line-height=
:17px"></span></div><div><span style=3D"line-height:17px">Please keep in mi=
nd that the primary goal of this proposal (at present) is to measure the in=
terest/response of such a mechanism. But I do note several related proposal=
s such as small/inplace vectors, inplace strings, inplace any/variant - i.e=
.. there seems to be a theme here.</span><br></div></div></div></blockquote>=
<div><br>Themes are TS material ;) Like networking or filesystems.<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/e725d932-5fbd-4ac9-b707-66ab6e02a413%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/e725d932-5fbd-4ac9-b707-66ab6e02a413=
%40isocpp.org</a>.<br />

------=_Part_1079_155533886.1468551469903--

------=_Part_1078_887351346.1468551469902--

.

------=_Part_1331_1705108552.1468551696159
Content-Type: multipart/alternative;
 boundary="----=_Part_1332_1633833287.1468551696159"

------=_Part_1332_1633833287.1468551696159
Content-Type: text/plain; charset=UTF-8



On Thursday, July 14, 2016 at 8:35:42 PM UTC-4, Richard Smith wrote:
>
> On Thu, Jul 14, 2016 at 3:56 PM, Carl Cook <carl...@gmail.com
> <javascript:>> wrote:
>>
>>
>>    - What's the difference between inplace_function and LLVM's
>>    function_ref?
>>       - Excellent point - I've not seen function_ref until today
>>          - One difference - an inplace_function can be
>>          stored/copied/moved, even for non-trivial callable objects (for
>>          function_ref you'd need a second step of converting this to a std::function
>>          before storing/copying)
>>          - Another difference - I am not convinced function_ref
>>          successfully captures closures correctly (at least in GCC on -O1 or above,
>>          it doesn't appear to capture out of scope variables by reference or copy)
>>
>> llvm::function_ref doesn't capture anything, and is not supposed to --
> it's a *non-owning* handle to a callable that outlives the handle.
> (llvm::function_ref is to std::function as std::string_view is to
> std::string.) This is a feature and a design goal of llvm::function_ref,
> but I think it means it's addressing a fundamentally different problem than
> the one you're tackling here (which seems to be essentially, "let me
> control the size and alignment in std::function's small function
> optimization")
>

It's more than that, because `inplace_function` *never* allocates memory.
If the type you pass can't fit into the buffer... you get a hard compile
error.

It's more like the difference between having a fixed-length string class
and having a class that lets you control the small buffer size. With the
former, you say "this string will have 31 characters *maximum*, all stored
within this object." With the latter, you say "if the string is less than
32 characters long, it will not allocate memory."

--
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/a7a1c9fe-5317-472e-b597-b830d4254d66%40isocpp.org.

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

<div dir=3D"ltr"><br><br>On Thursday, July 14, 2016 at 8:35:42 PM UTC-4, Ri=
chard Smith wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;marg=
in-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"=
ltr"><div><div class=3D"gmail_quote">On Thu, Jul 14, 2016 at 3:56 PM, Carl =
Cook <span dir=3D"ltr">&lt;<a href=3D"javascript:" target=3D"_blank" gdf-ob=
fuscated-mailto=3D"xsBxwvVpCwAJ" rel=3D"nofollow" onmousedown=3D"this.href=
=3D&#39;javascript:&#39;;return true;" onclick=3D"this.href=3D&#39;javascri=
pt:&#39;;return true;">carl...@gmail.com</a>&gt;</span> wrote:<blockquote c=
lass=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;=
padding-left:1ex"><div dir=3D"ltr"><div><ul><li>What&#39;s the difference b=
etween inplace_function and LLVM&#39;s function_ref?</li><ul><li>Excellent =
point - I&#39;ve not seen function_ref until today</li><ul><li>One differen=
ce - an inplace_function can be stored/copied/moved, even for non-trivial c=
allable objects (for function_ref you&#39;d need a second step of convertin=
g this to a std::function before storing/copying)</li><li>Another differenc=
e - I am not convinced function_ref successfully captures closures correctl=
y (at least in GCC on -O1 or above, it doesn&#39;t appear to capture out of=
 scope variables by reference or copy)</li></ul></ul></ul></div></div></blo=
ckquote><div>llvm::function_ref doesn&#39;t capture anything, and is not su=
pposed to -- it&#39;s a *non-owning* handle to a callable that outlives the=
 handle. (llvm::function_ref is to std::function as std::string_view is to =
std::string.) This is a feature and a design goal of llvm::function_ref, bu=
t I think it means it&#39;s addressing a fundamentally different problem th=
an the one you&#39;re tackling here (which seems to be essentially, &quot;l=
et me control the size and alignment in std::function&#39;s small function =
optimization&quot;)<br></div></div></div></div></blockquote><div><br>It&#39=
;s more than that, because `inplace_function` <i>never</i> allocates memory=
.. If the type you pass can&#39;t fit into the buffer... you get a hard comp=
ile error.<br><br>It&#39;s more like the difference between having a fixed-=
length string class and having a class that lets you control the small buff=
er size. With the former, you say &quot;this string will have 31 characters=
 <i>maximum</i>, all stored within this object.&quot; With the latter, you =
say &quot;if the string is less than 32 characters long, it will not alloca=
te memory.&quot;</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/a7a1c9fe-5317-472e-b597-b830d4254d66%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/a7a1c9fe-5317-472e-b597-b830d4254d66=
%40isocpp.org</a>.<br />

------=_Part_1332_1633833287.1468551696159--

------=_Part_1331_1705108552.1468551696159--

.

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

On 14 July 2016 at 21:57, Nicol Bolas <jmckesson@gmail.com> wrote:

> It's not a question of "should the standard library care about
> high-performance code". It's a question of "how many high-performance
> corner cases should be in the standard library?" You can keep adding stuff
> to cover corner cases ad infinitum. At some point, you have to draw a line.
>

Why?

I remember back in '12 when the big complaint was that the C++ Standard
Library was too small.  I must have been sleeping when that got solved.

My personal criterion are:

   - Things that people keep inventing in multiple places
   - Things that are hard to write correctly

Remember: we are talking about a type which, in the very next section, you
> admit "will only be used in specialized cases". To me, the standard library
> should be for tools that are of general use.
>

That's you.  And no one is forcing you to use the other stuff.


> That's why I like the idea of having a dedicated TS specifically for these
> types of things. I'd love to see a TS full of `small_vector`,
> `small_basic_string`, `inplace_function`, and so forth (but not
> `flat_set/map`. Those *need to be* in the standard library). Please don't
> look on TS's as some kind of ghetto for things that are not really
> standard. Yes, they really are standard, they really are supplied by
> compiler vendors, and they really are available.
>

And people who work on them expect the stuff in them to go into the IS at
some point.  If you wish to change the focus of TSes, you need to come to
meetings and present your case.


> This actually brings up a small technical deficiency with the current
> proposal: no interop with `std::function`. Well, besides the obvious fact
> that `inplace_function` is a callable and you could therefore shove one
> into a `function` and vice-versa.
>

Why?  What are the actual use cases for that?
--
 Nevin ":-)" Liber  <mailto:nevin@eviloverlord.com>  +1-847-691-1404

--
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/CAGg_6%2BMnvpxu4mfYAHBSCh-_vNW93A8AfaLykts8%2BF_ytfSpaQ%40mail.gmail.com.

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

<div dir=3D"ltr">On 14 July 2016 at 21:57, Nicol Bolas <span dir=3D"ltr">&l=
t;<a href=3D"mailto:jmckesson@gmail.com" target=3D"_blank">jmckesson@gmail.=
com</a>&gt;</span> wrote:<br><div class=3D"gmail_extra"><div class=3D"gmail=
_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border=
-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div>It&#39;s not a=
 question of &quot;should the standard library care about high-performance =
code&quot;. It&#39;s a question of &quot;how many high-performance corner c=
ases should be in the standard library?&quot; You can keep adding stuff to =
cover corner cases ad infinitum. At some point, you have to draw a line.<br=
></div></div></blockquote><div><br></div><div>Why?</div><div><br></div><div=
>I remember back in &#39;12 when the big complaint was that the C++ Standar=
d Library was too small.=C2=A0 I must have been sleeping when that got solv=
ed.</div><div><br></div><div>My personal criterion are:</div><div><ul><li>T=
hings that people keep inventing in multiple places</li><li>Things that are=
 hard to write correctly=C2=A0<br></li></ul></div><blockquote class=3D"gmai=
l_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left=
:1ex"><div dir=3D"ltr"><div>Remember: we are talking about a type which, in=
 the very next section, you admit &quot;will only be used in specialized ca=
ses&quot;. To me, the standard library should be for tools that are of gene=
ral use.<br></div></div></blockquote><div><br></div><div>That&#39;s you.=C2=
=A0 And no one is forcing you to use the other stuff.</div><div>=C2=A0</div=
><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1=
px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div>That&#39;s why I like=
 the idea of having a dedicated TS specifically for these types of things. =
I&#39;d love to see a TS full of `small_vector`, `small_basic_string`, `inp=
lace_function`, and so forth (but not `flat_set/map`. Those <i>need to be</=
i> in the standard library). Please don&#39;t look on TS&#39;s as some kind=
 of ghetto for things that are not really standard. Yes, they really are st=
andard, they really are supplied by compiler vendors, and they really are a=
vailable.<br></div></div></blockquote><div><br></div><div>And people who wo=
rk on them expect the stuff in them to go into the IS at some point.=C2=A0 =
If you wish to change the focus of TSes, you need to come to meetings and p=
resent your case.</div><div>=C2=A0</div><blockquote class=3D"gmail_quote" s=
tyle=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div=
 dir=3D"ltr"><div>This actually brings up a small technical deficiency with=
 the current proposal: no interop with `std::function`. Well, besides the o=
bvious fact that `inplace_function` is a callable and you could therefore s=
hove one into a `function` and vice-versa.<br></div></div></blockquote><div=
><br></div><div>Why?=C2=A0 What are the actual use cases for that?</div></d=
iv>-- <br><div class=3D"gmail_signature" data-smartmail=3D"gmail_signature"=
><div dir=3D"ltr"><div><div dir=3D"ltr"><div>=C2=A0Nevin &quot;:-)&quot; Li=
ber=C2=A0 &lt;mailto:<a href=3D"mailto:nevin@eviloverlord.com" target=3D"_b=
lank">nevin@eviloverlord.com</a>&gt; =C2=A0+1-847-691-1404</div></div></div=
></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/CAGg_6%2BMnvpxu4mfYAHBSCh-_vNW93A8Afa=
Lykts8%2BF_ytfSpaQ%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
>https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAGg_6%2BMnvp=
xu4mfYAHBSCh-_vNW93A8AfaLykts8%2BF_ytfSpaQ%40mail.gmail.com</a>.<br />

--001a113df136c70a900537a4156e--

.

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

On 14 July 2016 at 21:57, Nicol Bolas <jmckesson@gmail.com> wrote:

>
> It's not a question of "should the standard library care about
> high-performance code". It's a question of "how many high-performance
> corner cases should be in the standard library?" You can keep adding stuff
> to cover corner cases ad infinitum. At some point, you have to draw a line.
>
[...]

> This actually brings up a small technical deficiency with the current
> proposal: no interop with `std::function`. Well, besides the obvious fact
> that `inplace_function` is a callable and you could therefore shove one
> into a `function` and vice-versa.
>
> We ought to be able to convert between the two without creating overhead.
>

Isn't that just a corner case we ought to be drawing the line at?
--
 Nevin ":-)" Liber  <mailto:nevin@eviloverlord.com>  +1-847-691-1404

--
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/CAGg_6%2BNEu8s5GVHQidjs8NPRkDwqGg2S3xDMseP41Y_jq77DVQ%40mail.gmail.com.

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

<div dir=3D"ltr">On 14 July 2016 at 21:57, Nicol Bolas <span dir=3D"ltr">&l=
t;<a href=3D"mailto:jmckesson@gmail.com" target=3D"_blank">jmckesson@gmail.=
com</a>&gt;</span> wrote:<br><div class=3D"gmail_extra"><div class=3D"gmail=
_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border=
-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><br><div>It&#39;s n=
ot a question of &quot;should the standard library care about high-performa=
nce code&quot;. It&#39;s a question of &quot;how many high-performance corn=
er cases should be in the standard library?&quot; You can keep adding stuff=
 to cover corner cases ad infinitum. At some point, you have to draw a line=
..<br></div></div></blockquote><div>[...]=C2=A0</div><blockquote class=3D"gm=
ail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-le=
ft:1ex"><div dir=3D"ltr"><div>This actually brings up a small technical def=
iciency with the current proposal: no interop with `std::function`. Well, b=
esides the obvious fact that `inplace_function` is a callable and you could=
 therefore shove one into a `function` and vice-versa.<br></div><div><br>We=
 ought to be able to convert between the two without creating overhead. </d=
iv></div></blockquote><div><br></div><div>Isn&#39;t that just a corner case=
 we ought to be drawing the line at?</div></div>-- <br><div class=3D"gmail_=
signature" data-smartmail=3D"gmail_signature"><div dir=3D"ltr"><div><div di=
r=3D"ltr"><div>=C2=A0Nevin &quot;:-)&quot; Liber=C2=A0 &lt;mailto:<a href=
=3D"mailto:nevin@eviloverlord.com" target=3D"_blank">nevin@eviloverlord.com=
</a>&gt; =C2=A0+1-847-691-1404</div></div></div></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/CAGg_6%2BNEu8s5GVHQidjs8NPRkDwqGg2S3x=
DMseP41Y_jq77DVQ%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAGg_6%2BNEu8s5=
GVHQidjs8NPRkDwqGg2S3xDMseP41Y_jq77DVQ%40mail.gmail.com</a>.<br />

--001a114093ce9571670537a41d6e--

.

------=_Part_1381_1154964299.1468557017645
Content-Type: multipart/alternative;
 boundary="----=_Part_1382_1518302802.1468557017646"

------=_Part_1382_1518302802.1468557017646
Content-Type: text/plain; charset=UTF-8

On Thursday, July 14, 2016 at 11:19:24 PM UTC-4, Nevin ":-)" Liber wrote:
>
> On 14 July 2016 at 21:57, Nicol Bolas <jmck...@gmail.com> wrote:
>
>> It's not a question of "should the standard library care about
>> high-performance code". It's a question of "how many high-performance
>> corner cases should be in the standard library?" You can keep adding stuff
>> to cover corner cases ad infinitum. At some point, you have to draw a line.
>>
>
> Why?
>
> I remember back in '12 when the big complaint was that the C++ Standard
> Library was too small.  I must have been sleeping when that got solved.
>

I remember back in '12 when I completely disagreed with Herb Sutter's
statement to that effect. So I'm not really sure what point you're trying
to make. I've always felt that C++'s small standard library was a good
thing, not a problem to be "solved".

My personal criterion are:
>
>    - Things that people keep inventing in multiple places
>    - Things that are hard to write correctly
>
> Remember: we are talking about a type which, in the very next section, you
>> admit "will only be used in specialized cases". To me, the standard library
>> should be for tools that are of general use.
>>
>
> That's you.  And no one is forcing you to use the other stuff.
>

Generally speaking, people do not code in a vacuum. How other people code
affects your code, just as your code affects the code of others. Why?

Because you may need to share that code. And thus, your code needs to be
able to interoperate with theirs. If someone elses code allocates memory,
but your project doesn't allow unauthorized allocations, then you can't use
their code. If their strings are UTF-16s, then you're going to have to
convert your UTF-8s into UTF-16 if you want to use it. If you don't like
`enum class`es, but someone used an `enum class` in the interface to their
library, you're going to have to make your peace with that language feature
in order to use that library. If a library uses filesystem `path`s, but you
use C-style file IO (because you like performance), you're going to have to
write non-standard code in order to work with their system.

And so forth.

Some people do code in a vacuum, where the only code they talk to lives in
their own world. And that's fine. But let's not ignore the fact that a lot
of other people share code. And therefore, what code someone uses very much
affects others.

This is why standards are important. That's why `shared_ptr` is designed as
the "do everything" smart pointer. It is the smart pointer that can work
with *anything*. Despite its overhead compared to other possible
implementations, it is the lingua franca smart pointer.

The nice thing about the C++ standard library as it currently stands is
that it usually has only one answer to every general problem (that it
covers). Need a dynamic array? `vector`. Need a callback that can call
anything? `function`. Need a reference-counted shared ownership object?
`shared_ptr`. Need a way to communicate a value/exception between threads?
`promise/future`. Etc.

Every time the standard library tries to offer multiple ways to achieve the
same result, they screw things up. Just look at iostreams vs. C-standard
IO. C's IO is very fast and serviceable, but is horribly non-type-safe and
doesn't interoperate with `filesystem`. Iostreams has filesystem interop
(when the committee fixes that defect) and type-safety, but is very weak on
performance when type safety isn't an issue. Neither one is good; there is
only the one that is least painful.

We had C-standard string-to-number functions, which were unsafe. So we
tried to replace them with `stoX` and `to_string`, all of which are broken
by the fact that they sue `std::string` directly, not even allowing you to
use a string type with a different allocator. That attempt to replace
C-standard string conversions went *so badly* that C++17 is going to
replace the replacements with more string conversion functions. Converters
that seem so terrified of the mistakes of the C++11 converters that they
don't even use `string_view`, eschewing it for explicit `char*` ranges.

Imagine how much cleaner the standard library could be if iostreams were
just an adjacent TS, rather than a fully required part of the C++ standard.
Imagine how much refactoring and improvement could have been done on that
interface if backwards compatibility were not a requirement.

That's why I like the idea of having a dedicated TS specifically for these
>> types of things. I'd love to see a TS full of `small_vector`,
>> `small_basic_string`, `inplace_function`, and so forth (but not
>> `flat_set/map`. Those *need to be* in the standard library). Please
>> don't look on TS's as some kind of ghetto for things that are not really
>> standard. Yes, they really are standard, they really are supplied by
>> compiler vendors, and they really are available.
>>
>
> And people who work on them expect the stuff in them to go into the IS at
> some point.
>

So... there is a genuine intent to adopt a 2D graphics rendering system
into the C++ standard library at some point? Really?

If you wish to change the focus of TSes, you need to come to meetings and
> present your case.
>

>
This actually brings up a small technical deficiency with the current
>> proposal: no interop with `std::function`. Well, besides the obvious fact
>> that `inplace_function` is a callable and you could therefore shove one
>> into a `function` and vice-versa.
>>
>
> Why?  What are the actual use cases for that?
>

The use case of "someone used `std::function` in an interface, but I use
`std::inplace_function` internally, and I need to talk to their code."
Right now, `std::function` is how lots of C++ code takes callbacks, and for
good reason. But if I've wrapped some function in an `inplace_function`, I
still need to be able to talk to them.

It's basically the same thinking that allows a `unique_ptr` to be moved
into a `shared_ptr`.

--
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/d14a6548-9ddf-40c2-adc4-a046aff2d1e2%40isocpp.org.

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

<div dir=3D"ltr">On Thursday, July 14, 2016 at 11:19:24 PM UTC-4, Nevin &qu=
ot;:-)&quot; Liber 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">On 14 July 2016 at 21:57, Nicol Bolas <span dir=3D"ltr">&lt;<a =
target=3D"_blank" rel=3D"nofollow">jmck...@gmail.com</a>&gt;</span> wrote:<=
br><div><div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=
=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=
=3D"ltr"><div>It&#39;s
 not a question of &quot;should the standard library care about=20
high-performance code&quot;. It&#39;s a question of &quot;how many high-per=
formance=20
corner cases should be in the standard library?&quot; You can keep adding=
=20
stuff to cover corner cases ad infinitum. At some point, you have to=20
draw a line.<br></div></div></blockquote><div><br></div><div>Why?</div><div=
><br></div><div>I
 remember back in &#39;12 when the big complaint was that the C++ Standard=
=20
Library was too small.=C2=A0 I must have been sleeping when that got solved=
..</div></div></div></div></blockquote><div><br>I remember back in &#39;12 w=
hen I completely disagreed with Herb Sutter&#39;s statement to that effect.=
 So I&#39;m not really sure what point you&#39;re trying to make. I&#39;ve =
always felt that C++&#39;s small standard library was a good thing, not a p=
roblem to be &quot;solved&quot;.<br><br></div><blockquote class=3D"gmail_qu=
ote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padd=
ing-left: 1ex;"><div dir=3D"ltr"><div><div class=3D"gmail_quote"><div></div=
><div>My personal criterion are:</div><div><ul><li>Things that people keep =
inventing in multiple places</li><li>Things that are hard to write correctl=
y=C2=A0<br></li></ul></div><blockquote class=3D"gmail_quote" style=3D"margi=
n:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">=
<div>Remember:
 we are talking about a type which, in the very next section, you admit=20
&quot;will only be used in specialized cases&quot;. To me, the standard lib=
rary=20
should be for tools that are of general use.<br></div></div></blockquote><d=
iv><br></div><div>That&#39;s you.=C2=A0 And no one is forcing you to use th=
e other stuff.</div></div></div></div></blockquote><div><br>Generally speak=
ing, people do not code in a vacuum. How other people code affects your cod=
e, just as your code affects the code of others. Why?<br><br>Because you ma=
y need to share that code. And thus, your code needs to be able to interope=
rate with theirs. If someone elses code allocates memory, but your project =
doesn&#39;t allow unauthorized allocations, then you can&#39;t use their co=
de. If their strings are UTF-16s, then you&#39;re going to have to convert =
your UTF-8s into UTF-16 if you want to use it. If you don&#39;t like `enum =
class`es, but someone used an `enum class` in the interface to their librar=
y, you&#39;re going to have to make your peace with that language feature i=
n order to use that library. If a library uses filesystem `path`s, but you =
use C-style file IO (because you like performance), you&#39;re going to hav=
e to write non-standard code in order to work with their system.<br><br>And=
 so forth.<br><br>Some people do code in a vacuum, where the only code they=
 talk to lives in their own world. And that&#39;s fine. But let&#39;s not i=
gnore the fact that a lot of other people share code. And therefore, what c=
ode someone uses very much affects others.<br><br>This is why standards are=
 important. That&#39;s why `shared_ptr` is designed as the &quot;do everyth=
ing&quot; smart pointer. It is the smart pointer that can work with <i>anyt=
hing</i>. Despite its overhead compared to other possible implementations, =
it is the lingua franca smart pointer.<br><br>The nice thing about the C++ =
standard library as it currently stands is=20
that it usually has only one answer to every general problem (that it cover=
s). Need a=20
dynamic array? `vector`. Need a callback that can call anything?=20
`function`. Need a reference-counted shared ownership object?=20
`shared_ptr`. Need a way to communicate a value/exception between=20
threads? `promise/future`. Etc.<br><br>Every time the standard library trie=
s to offer multiple ways to achieve the same result, they screw things up. =
Just look at iostreams vs. C-standard IO. C&#39;s IO is very fast and servi=
ceable, but is horribly non-type-safe and doesn&#39;t interoperate with `fi=
lesystem`. Iostreams has filesystem interop (when the committee fixes that =
defect) and type-safety, but is very weak on performance when type safety i=
sn&#39;t an issue. Neither one is good; there is only the one that is least=
 painful.<br><br>We had C-standard string-to-number functions, which were u=
nsafe. So we tried to replace them with `stoX` and `to_string`, all of whic=
h are broken by the fact that they sue `std::string` directly, not even all=
owing you to use a string type with a different allocator. That attempt to =
replace C-standard string conversions went <i>so badly</i> that C++17 is go=
ing to replace the replacements with more string conversion functions. Conv=
erters that seem so terrified of the mistakes of the C++11 converters that =
they don&#39;t even use `string_view`, eschewing it for explicit `char*` ra=
nges.<br><br>Imagine how much cleaner the standard library could be if iost=
reams were just an adjacent TS, rather than a fully required part of the C+=
+ standard. Imagine how much refactoring and improvement could have been do=
ne on that interface if backwards compatibility were not a requirement.<br>=
<br></div><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"><blockquote class=3D"gmail_quote" style=3D"mar=
gin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr=
"><div>That&#39;s
 why I like the idea of having a dedicated TS specifically for these=20
types of things. I&#39;d love to see a TS full of `small_vector`,=20
`small_basic_string`, `inplace_function`, and so forth (but not=20
`flat_set/map`. Those <i>need to be</i> in the standard library). Please
 don&#39;t look on TS&#39;s as some kind of ghetto for things that are not=
=20
really standard. Yes, they really are standard, they really are supplied
 by compiler vendors, and they really are available.<br></div></div></block=
quote><div><br></div><div>And
 people who work on them expect the stuff in them to go into the IS at=20
some point.</div></div></div></div></blockquote><div><br>So... there is a g=
enuine intent to adopt a 2D graphics rendering system into the C++ standard=
 library at some point? Really?<br><br></div><blockquote class=3D"gmail_quo=
te" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;paddi=
ng-left: 1ex;"><div dir=3D"ltr"><div><div class=3D"gmail_quote"><div>If you=
 wish to change the focus of TSes, you need to come=20
to meetings and present your case.</div></div></div></div></blockquote><blo=
ckquote style=3D"margin: 0px 0px 0px 0.8ex; border-left: 1px solid rgb(204,=
 204, 204); padding-left: 1ex;" class=3D"gmail_quote"><div>=C2=A0</div></bl=
ockquote><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"><div=
><div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"marg=
in:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"=
><div>This
 actually brings up a small technical deficiency with the current=20
proposal: no interop with `std::function`. Well, besides the obvious=20
fact that `inplace_function` is a callable and you could therefore shove
 one into a `function` and vice-versa.<br></div></div></blockquote><div><br=
></div><div>Why?=C2=A0 What are the actual use cases for that?</div></div><=
/div></div></blockquote><div><br>The use case of &quot;someone used `std::f=
unction` in an interface, but I use `std::inplace_function` internally, and=
 I need to talk to their code.&quot; Right now, `std::function` is how lots=
 of C++ code takes callbacks, and for good reason. But if I&#39;ve wrapped =
some function in an `inplace_function`, I still need to be able to talk to =
them.<br><br>It&#39;s basically the same thinking that allows a `unique_ptr=
` to be moved into a `shared_ptr`.</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/d14a6548-9ddf-40c2-adc4-a046aff2d1e2%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/d14a6548-9ddf-40c2-adc4-a046aff2d1e2=
%40isocpp.org</a>.<br />

------=_Part_1382_1518302802.1468557017646--

------=_Part_1381_1154964299.1468557017645--

.

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

On 14 July 2016 at 23:30, Nicol Bolas <jmckesson@gmail.com> wrote:

> The use case of "someone used `std::function` in an interface, but I use
> `std::inplace_function` internally, and I need to talk to their code."
> Right now, `std::function` is how lots of C++ code takes callbacks, and for
> good reason. But if I've wrapped some function in an `inplace_function`, I
> still need to be able to talk to them.
>

Maybe std::function is the wrong vocabulary type for interfaces, just like
std::string is the wrong vocabulary type for interfaces, hence we will have
std::string_view.  Having something like llvm::function_ref that Richard
Smith described earlier might be a better fit (and LEWG might ask Carl to
add such a beast to his proposal).
--
 Nevin ":-)" Liber  <mailto:nevin@eviloverlord.com>  +1-847-691-1404

--
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/CAGg_6%2BMW9gAkGwgO03RZDj2%3DFn0tb6zxKXui0%2BdbxVtG3WjyGQ%40mail.gmail.com.

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

<div dir=3D"ltr"><div class=3D"gmail_extra">On 14 July 2016 at 23:30, Nicol=
 Bolas <span dir=3D"ltr">&lt;<a href=3D"mailto:jmckesson@gmail.com" target=
=3D"_blank">jmckesson@gmail.com</a>&gt;</span> wrote:<br><div class=3D"gmai=
l_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;borde=
r-left:1px #ccc solid;padding-left:1ex"><div>The use case of &quot;someone =
used `std::function` in an interface, but I use `std::inplace_function` int=
ernally, and I need to talk to their code.&quot; Right now, `std::function`=
 is how lots of C++ code takes callbacks, and for good reason. But if I&#39=
;ve wrapped some function in an `inplace_function`, I still need to be able=
 to talk to them.<br></div></blockquote></div><br>Maybe std::function is th=
e wrong vocabulary type for interfaces, just like std::string is the wrong =
vocabulary type for interfaces, hence we will have std::string_view.=C2=A0 =
Having something like llvm::function_ref that Richard Smith described earli=
er might be a better fit (and LEWG might ask Carl to add such a beast to hi=
s proposal).<br>-- <br><div data-smartmail=3D"gmail_signature"><div dir=3D"=
ltr"><div><div dir=3D"ltr"><div>=C2=A0Nevin &quot;:-)&quot; Liber=C2=A0 &lt=
;mailto:<a href=3D"mailto:nevin@eviloverlord.com" target=3D"_blank">nevin@e=
viloverlord.com</a>&gt; =C2=A0<a href=3D"tel:%2B1-847-691-1404" value=3D"+1=
8476911404" target=3D"_blank">+1-847-691-1404</a></div></div></div></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/CAGg_6%2BMW9gAkGwgO03RZDj2%3DFn0tb6zx=
KXui0%2BdbxVtG3WjyGQ%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfoote=
r">https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAGg_6%2BMW=
9gAkGwgO03RZDj2%3DFn0tb6zxKXui0%2BdbxVtG3WjyGQ%40mail.gmail.com</a>.<br />

--001a113df136a997370537a75cc0--

.

------=_Part_190_1624127528.1468573978381
Content-Type: multipart/alternative;
 boundary="----=_Part_191_69710619.1468573978382"

------=_Part_191_69710619.1468573978382
Content-Type: text/plain; charset=UTF-8

On Friday, 15 July 2016 02:35:42 UTC+2, Richard Smith wrote:
>
> llvm::function_ref doesn't capture anything, and is not supposed to --
> it's a *non-owning* handle to a callable that outlives the handle.
> (llvm::function_ref is to std::function as std::string_view is to
> std::string.) This is a feature and a design goal of llvm::function_ref,
> but I think it means it's addressing a fundamentally different problem than
> the one you're tackling here (which seems to be essentially, "let me
> control the size and alignment in std::function's small function
> optimization"
>

Understood. What caught me out is that compilers can aggressively limit the
scope of lambdas. Hence I believe the following is not legal usage:

int non_const_var = 0xf;
function_ref<int()> f_ref = [&]() { return non_const_var;};
return f_ref();



--
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/cd6e299d-7cec-4d8e-8a55-f25fd88d1b91%40isocpp.org.

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

<div dir=3D"ltr">On Friday, 15 July 2016 02:35:42 UTC+2, Richard Smith  wro=
te:<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"><div class=
=3D"gmail_quote"><div>llvm::function_ref doesn&#39;t capture anything, and =
is not supposed to -- it&#39;s a *non-owning* handle to a callable that out=
lives the handle. (llvm::function_ref is to std::function as std::string_vi=
ew is to std::string.) This is a feature and a design goal of llvm::functio=
n_ref, but I think it means it&#39;s addressing a fundamentally different p=
roblem than the one you&#39;re tackling here (which seems to be essentially=
, &quot;let me control the size and alignment in std::function&#39;s small =
function optimization&quot;</div></div></div></blockquote><div><br></div><d=
iv>Understood. What caught me out is that compilers can aggressively limit =
the scope of lambdas. Hence I believe the following is not legal usage:</di=
v><div><br></div><div><div class=3D"prettyprint" style=3D"border: 1px solid=
 rgb(187, 187, 187); word-wrap: break-word; background-color: rgb(250, 250,=
 250);"><code class=3D"prettyprint"><div class=3D"subprettyprint"><div clas=
s=3D"subprettyprint">int non_const_var =3D 0xf;</div><div class=3D"subprett=
yprint">function_ref&lt;int()&gt; f_ref =3D [&amp;]() { return non_const_va=
r;};</div><div class=3D"subprettyprint">return f_ref();</div></div></code><=
/div><br><br><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/cd6e299d-7cec-4d8e-8a55-f25fd88d1b91%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/cd6e299d-7cec-4d8e-8a55-f25fd88d1b91=
%40isocpp.org</a>.<br />

------=_Part_191_69710619.1468573978382--

------=_Part_190_1624127528.1468573978381--

.

------=_Part_94_2116630029.1468576827766
Content-Type: multipart/alternative;
 boundary="----=_Part_95_318663664.1468576827766"

------=_Part_95_318663664.1468576827766
Content-Type: text/plain; charset=UTF-8

On Friday, July 15, 2016 at 8:13:58 AM UTC+1, Nevin ":-)" Liber wrote:
>
> On 14 July 2016 at 23:30, Nicol Bolas <jmck...@gmail.com <javascript:>>
> wrote:
>
>> The use case of "someone used `std::function` in an interface, but I use
>> `std::inplace_function` internally, and I need to talk to their code."
>> Right now, `std::function` is how lots of C++ code takes callbacks, and for
>> good reason. But if I've wrapped some function in an `inplace_function`, I
>> still need to be able to talk to them.
>>
>
> Maybe std::function is the wrong vocabulary type for interfaces, just like
> std::string is the wrong vocabulary type for interfaces, hence we will have
> std::string_view.  Having something like llvm::function_ref that Richard
> Smith described earlier might be a better fit (and LEWG might ask Carl to
> add such a beast to his proposal).
> --
>

Isn't an std::function containing an std::reference_wrapper guaranteed not
to allocate? Is that different from llvm::function_ref?

-- gpd

--
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/e94d4f6d-e2c8-4b7d-a13a-0c10754212fd%40isocpp.org.

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

<div dir=3D"ltr">On Friday, July 15, 2016 at 8:13:58 AM UTC+1, Nevin &quot;=
:-)&quot; Liber 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"><div>On 14 July 2016 at 23:30, Nicol Bolas <span dir=3D"ltr">&lt;<=
a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"DQgNm7F_C=
wAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;javascript:&#39;;retu=
rn true;" onclick=3D"this.href=3D&#39;javascript:&#39;;return true;">jmck..=
..@gmail.com</a>&gt;</span> wrote:<br><div class=3D"gmail_quote"><blockquote=
 class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc soli=
d;padding-left:1ex"><div>The use case of &quot;someone used `std::function`=
 in an interface, but I use `std::inplace_function` internally, and I need =
to talk to their code.&quot; Right now, `std::function` is how lots of C++ =
code takes callbacks, and for good reason. But if I&#39;ve wrapped some fun=
ction in an `inplace_function`, I still need to be able to talk to them.<br=
></div></blockquote></div><br>Maybe std::function is the wrong vocabulary t=
ype for interfaces, just like std::string is the wrong vocabulary type for =
interfaces, hence we will have std::string_view.=C2=A0 Having something lik=
e llvm::function_ref that Richard Smith described earlier might be a better=
 fit (and LEWG might ask Carl to add such a beast to his proposal).<br>-- <=
br></div></div></blockquote><div><br>Isn&#39;t an std::function containing =
an std::reference_wrapper guaranteed not to allocate? Is that different fro=
m llvm::function_ref?</div><br>-- gpd<br></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/e94d4f6d-e2c8-4b7d-a13a-0c10754212fd%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/e94d4f6d-e2c8-4b7d-a13a-0c10754212fd=
%40isocpp.org</a>.<br />

------=_Part_95_318663664.1468576827766--

------=_Part_94_2116630029.1468576827766--

.

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

On Fri, Jul 15, 2016 at 2:12 AM, Carl Cook <carl.cook@gmail.com> wrote:

> On Friday, 15 July 2016 02:35:42 UTC+2, Richard Smith wrote:
>>
>> llvm::function_ref doesn't capture anything, and is not supposed to --
>> it's a *non-owning* handle to a callable that outlives the handle.
>> (llvm::function_ref is to std::function as std::string_view is to
>> std::string.) This is a feature and a design goal of llvm::function_ref,
>> but I think it means it's addressing a fundamentally different problem than
>> the one you're tackling here (which seems to be essentially, "let me
>> control the size and alignment in std::function's small function
>> optimization"
>>
>
> Understood. What caught me out is that compilers can aggressively limit
> the scope of lambdas. Hence I believe the following is not legal usage:
>
> int non_const_var = 0xf;
> function_ref<int()> f_ref = [&]() { return non_const_var;};
> return f_ref();
>

Right, it's exactly as broken as this:

string g() {
  string_view s_v = string("blah blah");
  return s_v;
}

In both cases, you've bound an object with reference semantics to a
(non-lifetime-extended) temporary object.

--
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/CAOfiQqmAmuesO%3Djq%2BKw3XYmS0B_j32LZ25oyw%2BXtykMtOYGHbg%40mail.gmail.com.

--001a11499a74eb59f50537b0c6c2
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 F=
ri, Jul 15, 2016 at 2:12 AM, Carl Cook <span dir=3D"ltr">&lt;<a href=3D"mai=
lto:carl.cook@gmail.com" target=3D"_blank">carl.cook@gmail.com</a>&gt;</spa=
n> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;b=
order-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><span class=3D=
"">On Friday, 15 July 2016 02:35:42 UTC+2, Richard Smith  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"><div class=3D"gmail_quote"><d=
iv>llvm::function_ref doesn&#39;t capture anything, and is not supposed to =
-- it&#39;s a *non-owning* handle to a callable that outlives the handle. (=
llvm::function_ref is to std::function as std::string_view is to std::strin=
g.) This is a feature and a design goal of llvm::function_ref, but I think =
it means it&#39;s addressing a fundamentally different problem than the one=
 you&#39;re tackling here (which seems to be essentially, &quot;let me cont=
rol the size and alignment in std::function&#39;s small function optimizati=
on&quot;</div></div></div></blockquote><div><br></div></span><div>Understoo=
d. What caught me out is that compilers can aggressively limit the scope of=
 lambdas. Hence I believe the following is not legal usage:</div><div><br><=
/div><div><div style=3D"border:1px solid rgb(187,187,187);word-wrap:break-w=
ord;background-color:rgb(250,250,250)"><code><div><div>int non_const_var =
=3D 0xf;</div><div>function_ref&lt;int()&gt; f_ref =3D [&amp;]() { return n=
on_const_var;};</div><div>return f_ref();</div></div></code></div></div></d=
iv></blockquote><div><br></div><div>Right, it&#39;s exactly as broken as th=
is:</div><div><br></div><div>string g() {</div><div>=C2=A0 string_view s_v =
=3D string(&quot;blah blah&quot;);</div><div>=C2=A0 return s_v;</div><div>}=
</div><div><br></div><div>In both cases, you&#39;ve bound an object with re=
ference semantics to a (non-lifetime-extended) temporary object.</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/CAOfiQqmAmuesO%3Djq%2BKw3XYmS0B_j32LZ=
25oyw%2BXtykMtOYGHbg%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfoote=
r">https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAOfiQqmAmu=
esO%3Djq%2BKw3XYmS0B_j32LZ25oyw%2BXtykMtOYGHbg%40mail.gmail.com</a>.<br />

--001a11499a74eb59f50537b0c6c2--

.

------=_Part_107_1610810078.1469967039446
Content-Type: multipart/alternative;
 boundary="----=_Part_108_1789092686.1469967039446"

------=_Part_108_1789092686.1469967039446
Content-Type: text/plain; charset=UTF-8

On Thursday, 14 July 2016 09:58:32 UTC+4, T. C. wrote:
>
> The allocator support in std::function has been zapped as of three weeks
> ago.
>

Do you know what the reason was for allocator support to be dropped?

--
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/a62356f7-99cd-496a-94ae-e53c9eb1a198%40isocpp.org.

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

<div dir=3D"ltr">On Thursday, 14 July 2016 09:58:32 UTC+4, T. C.  wrote:<bl=
ockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border=
-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div>The allocat=
or support in std::function has been zapped as of three weeks ago.=C2=A0</d=
iv></div></blockquote><div><br></div><div>Do you know what the reason was f=
or allocator support to be dropped?=C2=A0</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/a62356f7-99cd-496a-94ae-e53c9eb1a198%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/a62356f7-99cd-496a-94ae-e53c9eb1a198=
%40isocpp.org</a>.<br />

------=_Part_108_1789092686.1469967039446--

------=_Part_107_1610810078.1469967039446--

.

------=_Part_55_691771595.1469971769382
Content-Type: multipart/alternative;
 boundary="----=_Part_56_44143503.1469971769382"

------=_Part_56_44143503.1469971769382
Content-Type: text/plain; charset=UTF-8

In the example below, I am not passing a function_ref as the return value,
I am returning the result of the invocation of that function_ref, which I'd
assumed would be safe (i.e. return an integer).

However, it is the invocation that has failed, because the compiler has
decided that the lambda can already be cleaned up (from what I can tell,
looking at the disassembly).

So, granted that the function_ref certainly doesn't copy callable objects,
but I don't think it's useful for any lambda, unless that lambda is just
used to invoke a function (as in the llvm example usage).

On Friday, 15 July 2016 20:27:56 UTC+2, Richard Smith wrote:
>
> On Fri, Jul 15, 2016 at 2:12 AM, Carl Cook <carl...@gmail.com
> <javascript:>> wrote:
>
>> On Friday, 15 July 2016 02:35:42 UTC+2, Richard Smith wrote:
>>>
>>> llvm::function_ref doesn't capture anything, and is not supposed to --
>>> it's a *non-owning* handle to a callable that outlives the handle.
>>> (llvm::function_ref is to std::function as std::string_view is to
>>> std::string.) This is a feature and a design goal of llvm::function_ref,
>>> but I think it means it's addressing a fundamentally different problem than
>>> the one you're tackling here (which seems to be essentially, "let me
>>> control the size and alignment in std::function's small function
>>> optimization"
>>>
>>
>> Understood. What caught me out is that compilers can aggressively limit
>> the scope of lambdas. Hence I believe the following is not legal usage:
>>
>> int non_const_var = 0xf;
>> function_ref<int()> f_ref = [&]() { return non_const_var;};
>> return f_ref();
>>
>
> Right, it's exactly as broken as this:
>
> string g() {
>   string_view s_v = string("blah blah");
>   return s_v;
> }
>
> In both cases, you've bound an object with reference semantics to a
> (non-lifetime-extended) temporary object.
>

--
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/c3bc751f-5586-44d5-ba6c-4c3d6708e4ad%40isocpp.org.

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

<div dir=3D"ltr">In the example below, I am not passing a function_ref as t=
he return value, I am returning the result of the invocation of that functi=
on_ref, which I&#39;d assumed would be safe (i.e. return an integer).<div><=
br></div><div>However, it is the invocation that has failed, because the co=
mpiler has decided that the lambda can already be cleaned up (from what I c=
an tell, looking at the disassembly).</div><div><br></div><div>So, granted =
that the function_ref certainly doesn&#39;t copy callable objects, but I do=
n&#39;t think it&#39;s useful for any lambda, unless that lambda is just us=
ed to invoke a function (as in the llvm example usage).<br><br>On Friday, 1=
5 July 2016 20:27:56 UTC+2, Richard Smith  wrote:<blockquote class=3D"gmail=
_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;p=
adding-left: 1ex;"><div dir=3D"ltr"><div><div class=3D"gmail_quote">On Fri,=
 Jul 15, 2016 at 2:12 AM, Carl Cook <span dir=3D"ltr">&lt;<a href=3D"javasc=
ript:" target=3D"_blank" gdf-obfuscated-mailto=3D"PLqVwXikCwAJ" rel=3D"nofo=
llow" onmousedown=3D"this.href=3D&#39;javascript:&#39;;return true;" onclic=
k=3D"this.href=3D&#39;javascript:&#39;;return true;">carl...@gmail.com</a>&=
gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 =
0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><span>=
On Friday, 15 July 2016 02:35:42 UTC+2, Richard Smith  wrote:<blockquote cl=
ass=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #cc=
c solid;padding-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_quote"><div>=
llvm::function_ref doesn&#39;t capture anything, and is not supposed to -- =
it&#39;s a *non-owning* handle to a callable that outlives the handle. (llv=
m::function_ref is to std::function as std::string_view is to std::string.)=
 This is a feature and a design goal of llvm::function_ref, but I think it =
means it&#39;s addressing a fundamentally different problem than the one yo=
u&#39;re tackling here (which seems to be essentially, &quot;let me control=
 the size and alignment in std::function&#39;s small function optimization&=
quot;</div></div></div></blockquote><div><br></div></span><div>Understood. =
What caught me out is that compilers can aggressively limit the scope of la=
mbdas. Hence I believe the following is not legal usage:</div><div><br></di=
v><div><div style=3D"border:1px solid rgb(187,187,187);word-wrap:break-word=
;background-color:rgb(250,250,250)"><code><div><div>int non_const_var =3D 0=
xf;</div><div>function_ref&lt;int()&gt; f_ref =3D [&amp;]() { return non_co=
nst_var;};</div><div>return f_ref();</div></div></code></div></div></div></=
blockquote><div><br></div><div>Right, it&#39;s exactly as broken as this:</=
div><div><br></div><div>string g() {</div><div>=C2=A0 string_view s_v =3D s=
tring(&quot;blah blah&quot;);</div><div>=C2=A0 return s_v;</div><div>}</div=
><div><br></div><div>In both cases, you&#39;ve bound an object with referen=
ce semantics to a (non-lifetime-extended) temporary object.</div></div></di=
v></div>
</blockquote></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/c3bc751f-5586-44d5-ba6c-4c3d6708e4ad%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/c3bc751f-5586-44d5-ba6c-4c3d6708e4ad=
%40isocpp.org</a>.<br />

------=_Part_56_44143503.1469971769382--

------=_Part_55_691771595.1469971769382--

.

<html><head></head><body lang=3D"en-US" style=3D"background-color: rgb(255,=
 255, 255); line-height: initial;">                                        =
                                              <div style=3D"width: 100%; fo=
nt-size: initial; font-family: Calibri, 'Slate Pro', sans-serif, sans-serif=
; color: rgb(31, 73, 125); text-align: initial; background-color: rgb(255, =
255, 255);">It never worked. No one implemented it.&nbsp;</div><div style=
=3D"width: 100%; font-size: initial; font-family: Calibri, 'Slate Pro', san=
s-serif, sans-serif; color: rgb(31, 73, 125); text-align: initial; backgrou=
nd-color: rgb(255, 255, 255);"><br></div><div style=3D"width: 100%; font-si=
ze: initial; font-family: Calibri, 'Slate Pro', sans-serif, sans-serif; col=
or: rgb(31, 73, 125); text-align: initial; background-color: rgb(255, 255, =
255);">Type erasure + allocator.... erasure? + std::funtion semantics &nbsp=
;Etc</div><div style=3D"width: 100%; font-size: initial; font-family: Calib=
ri, 'Slate Pro', sans-serif, sans-serif; color: rgb(31, 73, 125); text-alig=
n: initial; background-color: rgb(255, 255, 255);">Hard/impossible?</div><d=
iv style=3D"width: 100%; font-size: initial; font-family: Calibri, 'Slate P=
ro', sans-serif, sans-serif; color: rgb(31, 73, 125); text-align: initial; =
background-color: rgb(255, 255, 255);"><br></div>                          =
                                                                           =
                                <div style=3D"width: 100%; font-size: initi=
al; font-family: Calibri, 'Slate Pro', sans-serif, sans-serif; color: rgb(3=
1, 73, 125); text-align: initial; background-color: rgb(255, 255, 255);"><b=
r style=3D"display:initial"></div>                                         =
                                                                           =
                                                                           =
    <div style=3D"font-size: initial; font-family: Calibri, 'Slate Pro', sa=
ns-serif, sans-serif; color: rgb(31, 73, 125); text-align: initial; backgro=
und-color: rgb(255, 255, 255);">Sent&nbsp;from&nbsp;my&nbsp;BlackBerry&nbsp=
;portable&nbsp;Babbage&nbsp;Device</div>                                   =
                                                                           =
                                                                    <table =
width=3D"100%" style=3D"background-color:white;border-spacing:0px;"> <tbody=
><tr><td colspan=3D"2" style=3D"font-size: initial; text-align: initial; ba=
ckground-color: rgb(255, 255, 255);">                           <div style=
=3D"border-style: solid none none; border-top-color: rgb(181, 196, 223); bo=
rder-top-width: 1pt; padding: 3pt 0in 0in; font-family: Tahoma, 'BB Alpha S=
ans', 'Slate Pro'; font-size: 10pt;">  <div><b>From: </b>Carl Cook</div><di=
v><b>Sent: </b>Sunday, July 31, 2016 8:10 AM</div><div><b>To: </b>ISO C++ S=
tandard - Future Proposals</div><div><b>Reply To: </b>std-proposals@isocpp.=
org</div><div><b>Subject: </b>Re: [std-proposals] Proposal - non allocating=
 std::function</div></div></td></tr></tbody></table><div style=3D"border-st=
yle: solid none none; border-top-color: rgb(186, 188, 209); border-top-widt=
h: 1pt; font-size: initial; text-align: initial; background-color: rgb(255,=
 255, 255);"></div><br><div id=3D"_originalContent" style=3D""><div dir=3D"=
ltr">On Thursday, 14 July 2016 09:58:32 UTC+4, T. C.  wrote:<blockquote cla=
ss=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #=
ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div>The allocator support i=
n std::function has been zapped as of three weeks ago.&nbsp;</div></div></b=
lockquote><div><br></div><div>Do you know what the reason was for allocator=
 support to be dropped?&nbsp;</div></div>

<p></p>

-- <br>
You received this message because you are subscribed to the Google Groups "=
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/a62356f7-99cd-496a-94ae-e53c9eb1a198%=
40isocpp.org?utm_medium=3Demail&amp;utm_source=3Dfooter">https://groups.goo=
gle.com/a/isocpp.org/d/msgid/std-proposals/a62356f7-99cd-496a-94ae-e53c9eb1=
a198%40isocpp.org</a>.<br>
<br><!--end of _originalContent --></div></body></html>

<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/20160731134138.4898897.13173.14899%40=
gmail.com?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.com=
/a/isocpp.org/d/msgid/std-proposals/20160731134138.4898897.13173.14899%40gm=
ail.com</a>.<br />

.

------=_Part_745_128758336.1469972697964
Content-Type: multipart/alternative;
 boundary="----=_Part_746_1566959606.1469972697964"

------=_Part_746_1566959606.1469972697964
Content-Type: text/plain; charset=UTF-8

On Sunday, July 31, 2016 at 8:10:39 AM UTC-4, Carl Cook wrote:
>
> On Thursday, 14 July 2016 09:58:32 UTC+4, T. C. wrote:
>>
>> The allocator support in std::function has been zapped as of three weeks
>> ago.
>>
>
> Do you know what the reason was for allocator support to be dropped?
>

According to the proposal that drops it <http://wg21.link/P0302>, it was
because the whole design was generally considered faulty, with a number of
open defect reports on them. These faults lead to none of the major
standard library implementations doing it right. libstdc++ never even
bothered to offer the allocator constructor overloads. libc++ provided the
constructors, but never used the allocators. The closest one to right was
VS, which would use the allocators, but didn't propagate them correctly on
assignment.

--
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/14df876d-e382-469c-b755-5d285788c7fa%40isocpp.org.

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

<div dir=3D"ltr">On Sunday, July 31, 2016 at 8:10:39 AM UTC-4, Carl Cook wr=
ote:<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">On Thursd=
ay, 14 July 2016 09:58:32 UTC+4, T. C.  wrote:<blockquote class=3D"gmail_qu=
ote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding=
-left:1ex"><div dir=3D"ltr"><div>The allocator support in std::function has=
 been zapped as of three weeks ago.=C2=A0</div></div></blockquote><div><br>=
</div><div>Do you know what the reason was for allocator support to be drop=
ped?=C2=A0</div></div></blockquote><div><br>According to the <a href=3D"htt=
p://wg21.link/P0302">proposal that drops it</a>, it was because the whole d=
esign was generally considered faulty, with a number of open defect reports=
 on them. These faults lead to none of the major standard library implement=
ations doing it right. libstdc++ never even bothered to offer the allocator=
 constructor overloads. libc++ provided the constructors, but never used th=
e allocators. The closest one to right was VS, which would use the allocato=
rs, but didn&#39;t propagate them correctly on assignment.<br><br></div></d=
iv>

<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/14df876d-e382-469c-b755-5d285788c7fa%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/14df876d-e382-469c-b755-5d285788c7fa=
%40isocpp.org</a>.<br />

------=_Part_746_1566959606.1469972697964--

------=_Part_745_128758336.1469972697964--

.

On 31 July 2016 at 16:44, Nicol Bolas <jmckesson@gmail.com> wrote:
>> Do you know what the reason was for allocator support to be dropped?
> According to the proposal that drops it, it was because the whole design was
> generally considered faulty, with a number of open defect reports on them.
> These faults lead to none of the major standard library implementations
> doing it right. libstdc++ never even bothered to offer the allocator
> constructor overloads. libc++ provided the constructors, but never used the
> allocators. The closest one to right was VS, which would use the allocators,
> but didn't propagate them correctly on assignment.

The problem with correct propagation is that type erasure eradicates
all knowledge of what types
the propagation should be queried for. The mixture of purely
compile-time information of the propagation
traits and the complete lack of any such information at the point of
assignment due to type erasure is a fairly bad mixture.

--
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/CAFk2RUYiZ5kmNrgwS5URaW0tJPhi%2B1C1y-1XuysU543xaW82ZA%40mail.gmail.com.

.

------=_Part_723_230869431.1469973202280
Content-Type: multipart/alternative;
 boundary="----=_Part_724_239184812.1469973202280"

------=_Part_724_239184812.1469973202280
Content-Type: text/plain; charset=UTF-8



On Friday, July 15, 2016 at 3:13:58 AM UTC-4, Nevin ":-)" Liber wrote:
>
> On 14 July 2016 at 23:30, Nicol Bolas <jmck...@gmail.com <javascript:>>
> wrote:
>
>> The use case of "someone used `std::function` in an interface, but I use
>> `std::inplace_function` internally, and I need to talk to their code."
>> Right now, `std::function` is how lots of C++ code takes callbacks, and for
>> good reason. But if I've wrapped some function in an `inplace_function`, I
>> still need to be able to talk to them.
>>
>
> Maybe std::function is the wrong vocabulary type for interfaces, just like
> std::string is the wrong vocabulary type for interfaces, hence we will have
> std::string_view.  Having something like llvm::function_ref that Richard
> Smith described earlier might be a better fit (and LEWG might ask Carl to
> add such a beast to his proposal).
>

That's a really good analogy. I think the principle concern for the user is
this. `string_view` is a great interface type because you can use it to
construct pretty much any kind of string you like. It isn't limited to just
`std::string` construction. Would a hypothetical `function_view` have an
interface that could be used to construct any kind of function wrapper?
That is, how could it expose the actual type of the callable in such a way
that someone could copy it out?

Though we could probably get away with just allowing it to be converted to
a `function`. Or rather more specifically, allowing `function` to be
constructed from a `function_view`.

--
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/892618b7-19a9-4950-b552-ea5d5185362f%40isocpp.org.

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

<div dir=3D"ltr"><br><br>On Friday, July 15, 2016 at 3:13:58 AM UTC-4, Nevi=
n &quot;:-)&quot; Liber wrote:<blockquote class=3D"gmail_quote" style=3D"ma=
rgin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">=
<div dir=3D"ltr"><div>On 14 July 2016 at 23:30, Nicol Bolas <span dir=3D"lt=
r">&lt;<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"D=
QgNm7F_CwAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;javascript:&#=
39;;return true;" onclick=3D"this.href=3D&#39;javascript:&#39;;return true;=
">jmck...@gmail.com</a>&gt;</span> wrote:<br><div class=3D"gmail_quote"><bl=
ockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #=
ccc solid;padding-left:1ex"><div>The use case of &quot;someone used `std::f=
unction` in an interface, but I use `std::inplace_function` internally, and=
 I need to talk to their code.&quot; Right now, `std::function` is how lots=
 of C++ code takes callbacks, and for good reason. But if I&#39;ve wrapped =
some function in an `inplace_function`, I still need to be able to talk to =
them.<br></div></blockquote></div><br>Maybe std::function is the wrong voca=
bulary type for interfaces, just like std::string is the wrong vocabulary t=
ype for interfaces, hence we will have std::string_view.=C2=A0 Having somet=
hing like llvm::function_ref that Richard Smith described earlier might be =
a better fit (and LEWG might ask Carl to add such a beast to his proposal).=
<br></div></div></blockquote><div><br>That&#39;s a really good analogy. I t=
hink the principle concern for the user is this. `string_view` is a great i=
nterface type because you can use it to construct pretty much any kind of s=
tring you like. It isn&#39;t limited to just `std::string` construction. Wo=
uld a hypothetical `function_view` have an interface that could be used to =
construct any kind of function wrapper? That is, how could it expose the ac=
tual type of the callable in such a way that someone could copy it out?<br>=
<br>Though we could probably get away with just allowing it to be converted=
 to a `function`. Or rather more specifically, allowing `function` to be co=
nstructed from a `function_view`.<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/892618b7-19a9-4950-b552-ea5d5185362f%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/892618b7-19a9-4950-b552-ea5d5185362f=
%40isocpp.org</a>.<br />

------=_Part_724_239184812.1469973202280--

------=_Part_723_230869431.1469973202280--

.

------=_Part_721_473912543.1469973486218
Content-Type: multipart/alternative;
 boundary="----=_Part_722_394036172.1469973486218"

------=_Part_722_394036172.1469973486218
Content-Type: text/plain; charset=UTF-8

On Friday, July 15, 2016 at 6:00:28 AM UTC-4, Giovanni Piero Deretta wrote:
>
> On Friday, July 15, 2016 at 8:13:58 AM UTC+1, Nevin ":-)" Liber wrote:
>>
>> On 14 July 2016 at 23:30, Nicol Bolas <jmck...@gmail.com> wrote:
>>
>>> The use case of "someone used `std::function` in an interface, but I use
>>> `std::inplace_function` internally, and I need to talk to their code."
>>> Right now, `std::function` is how lots of C++ code takes callbacks, and for
>>> good reason. But if I've wrapped some function in an `inplace_function`, I
>>> still need to be able to talk to them.
>>>
>>
>> Maybe std::function is the wrong vocabulary type for interfaces, just
>> like std::string is the wrong vocabulary type for interfaces, hence we will
>> have std::string_view.  Having something like llvm::function_ref that
>> Richard Smith described earlier might be a better fit (and LEWG might ask
>> Carl to add such a beast to his proposal).
>> --
>>
>
> Isn't an std::function containing an std::reference_wrapper guaranteed not
> to allocate? Is that different from llvm::function_ref?
>

It's different in a couple of ways.

1: You can't guarantee that someone has given you a `function` containing
such a wrapper. So when you copy/move it around, you can't be guaranteed
that it won't allocate memory.

2: It's probably slower to invoke the callback through that than through a
hypothetical `function_view`.

While the whole `reference_wrapper` thing is a useful optimization, it's
really best to put that sort of thing in the type system.

--
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/5d419124-a1fd-489c-98cc-c92128676225%40isocpp.org.

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

<div dir=3D"ltr">On Friday, July 15, 2016 at 6:00:28 AM UTC-4, Giovanni Pie=
ro Deretta wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margi=
n-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"l=
tr">On Friday, July 15, 2016 at 8:13:58 AM UTC+1, Nevin &quot;:-)&quot; Lib=
er 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"><div>On 1=
4 July 2016 at 23:30, Nicol Bolas <span dir=3D"ltr">&lt;<a rel=3D"nofollow"=
>jmck...@gmail.com</a>&gt;</span> wrote:<br><div class=3D"gmail_quote"><blo=
ckquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #c=
cc solid;padding-left:1ex"><div>The use case of &quot;someone used `std::fu=
nction` in an interface, but I use `std::inplace_function` internally, and =
I need to talk to their code.&quot; Right now, `std::function` is how lots =
of C++ code takes callbacks, and for good reason. But if I&#39;ve wrapped s=
ome function in an `inplace_function`, I still need to be able to talk to t=
hem.<br></div></blockquote></div><br>Maybe std::function is the wrong vocab=
ulary type for interfaces, just like std::string is the wrong vocabulary ty=
pe for interfaces, hence we will have std::string_view.=C2=A0 Having someth=
ing like llvm::function_ref that Richard Smith described earlier might be a=
 better fit (and LEWG might ask Carl to add such a beast to his proposal).<=
br>-- <br></div></div></blockquote><div><br>Isn&#39;t an std::function cont=
aining an std::reference_wrapper guaranteed not to allocate? Is that differ=
ent from llvm::function_ref?</div></div></blockquote><br>It&#39;s different=
 in a couple of ways.<br><br>1: You can&#39;t guarantee that someone has gi=
ven you a `function` containing such a wrapper. So when you copy/move it ar=
ound, you can&#39;t be guaranteed that it won&#39;t allocate memory.<br><br=
>2: It&#39;s probably slower to invoke the callback through that than throu=
gh a hypothetical `function_view`.<br><br>While the whole `reference_wrappe=
r` thing is a useful optimization, it&#39;s really best to put that sort of=
 thing in the type system.<br></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/5d419124-a1fd-489c-98cc-c92128676225%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/5d419124-a1fd-489c-98cc-c92128676225=
%40isocpp.org</a>.<br />

------=_Part_722_394036172.1469973486218--

------=_Part_721_473912543.1469973486218--

.

------=_Part_3353_1240093709.1469974505991
Content-Type: multipart/alternative;
 boundary="----=_Part_3354_1922901637.1469974505991"

------=_Part_3354_1922901637.1469974505991
Content-Type: text/plain; charset=UTF-8

On Sunday, July 31, 2016 at 6:29:30 AM UTC-7, Carl Cook wrote:
>
> In the example below, I am not passing a function_ref as the return value,
> I am returning the result of the invocation of that function_ref, which I'd
> assumed would be safe (i.e. return an integer).
>
> However, it is the invocation that has failed, because the compiler has
> decided that the lambda can already be cleaned up (from what I can tell,
> looking at the disassembly).
>
> So, granted that the function_ref certainly doesn't copy callable objects,
> but I don't think it's useful for any lambda, unless that lambda is just
> used to invoke a function (as in the llvm example usage).
>
> On Friday, 15 July 2016 20:27:56 UTC+2, Richard Smith wrote:
>>
>> On Fri, Jul 15, 2016 at 2:12 AM, Carl Cook <carl...@gmail.com> wrote:
>>
>>> On Friday, 15 July 2016 02:35:42 UTC+2, Richard Smith wrote:
>>>>
>>>> llvm::function_ref doesn't capture anything, and is not supposed to --
>>>> it's a *non-owning* handle to a callable that outlives the handle.
>>>> (llvm::function_ref is to std::function as std::string_view is to
>>>> std::string.) This is a feature and a design goal of llvm::function_ref,
>>>> but I think it means it's addressing a fundamentally different problem than
>>>> the one you're tackling here (which seems to be essentially, "let me
>>>> control the size and alignment in std::function's small function
>>>> optimization"
>>>>
>>>
>>> Understood. What caught me out is that compilers can aggressively limit
>>> the scope of lambdas. Hence I believe the following is not legal usage:
>>>
>>> int non_const_var = 0xf;
>>> function_ref<int()> f_ref = [&]() { return non_const_var;};
>>> return f_ref();
>>>
>>
>> Right, it's exactly as broken as this:
>>
>> string g() {
>>   string_view s_v = string("blah blah");
>>   return s_v;
>> }
>>
>> In both cases, you've bound an object with reference semantics to a
>> (non-lifetime-extended) temporary object.
>>
>
[&]() { return non_const_var;}; is an expression whose value is a temporary
object. That temporary object is destroyed at the end of the full
expression
function_ref<int()> f_ref = [&]() { return non_const_var;};
Using the reference stored in f_ref to access that object after the end of
its lifetime results in undefined behavior.

--
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/ee95d8af-e8e9-47bc-9d61-d95551aac4f3%40isocpp.org.

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

<div dir=3D"ltr">On Sunday, July 31, 2016 at 6:29:30 AM UTC-7, Carl Cook wr=
ote:<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">In the ex=
ample below, I am not passing a function_ref as the return value, I am retu=
rning the result of the invocation of that function_ref, which I&#39;d assu=
med would be safe (i.e. return an integer).<div><br></div><div>However, it =
is the invocation that has failed, because the compiler has decided that th=
e lambda can already be cleaned up (from what I can tell, looking at the di=
sassembly).</div><div><br></div><div>So, granted that the function_ref cert=
ainly doesn&#39;t copy callable objects, but I don&#39;t think it&#39;s use=
ful for any lambda, unless that lambda is just used to invoke a function (a=
s in the llvm example usage).<br><br>On Friday, 15 July 2016 20:27:56 UTC+2=
, Richard Smith  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"><div><div class=3D"gmail_quote">On Fri, Jul 15, 2016 at 2:12 AM, Carl =
Cook <span dir=3D"ltr">&lt;<a rel=3D"nofollow">carl...@gmail.com</a>&gt;</s=
pan> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex=
;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><span>On Fri=
day, 15 July 2016 02:35:42 UTC+2, Richard Smith  wrote:<blockquote class=3D=
"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc soli=
d;padding-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_quote"><div>llvm::=
function_ref doesn&#39;t capture anything, and is not supposed to -- it&#39=
;s a *non-owning* handle to a callable that outlives the handle. (llvm::fun=
ction_ref is to std::function as std::string_view is to std::string.) This =
is a feature and a design goal of llvm::function_ref, but I think it means =
it&#39;s addressing a fundamentally different problem than the one you&#39;=
re tackling here (which seems to be essentially, &quot;let me control the s=
ize and alignment in std::function&#39;s small function optimization&quot;<=
/div></div></div></blockquote><div><br></div></span><div>Understood. What c=
aught me out is that compilers can aggressively limit the scope of lambdas.=
 Hence I believe the following is not legal usage:</div><div><br></div><div=
><div style=3D"border:1px solid rgb(187,187,187);word-wrap:break-word;backg=
round-color:rgb(250,250,250)"><code><div><div>int non_const_var =3D 0xf;</d=
iv><div>function_ref&lt;int()&gt; f_ref =3D [&amp;]() { return non_const_va=
r;};</div><div>return f_ref();</div></div></code></div></div></div></blockq=
uote><div><br></div><div>Right, it&#39;s exactly as broken as this:</div><d=
iv><br></div><div>string g() {</div><div>=C2=A0 string_view s_v =3D string(=
&quot;blah blah&quot;);</div><div>=C2=A0 return s_v;</div><div>}</div><div>=
<br></div><div>In both cases, you&#39;ve bound an object with reference sem=
antics to a (non-lifetime-extended) temporary object.</div></div></div></di=
v></blockquote></div></div></blockquote><div><br></div><div><font face=3D"c=
ourier new, monospace">[&amp;]() { return non_const_var;};</font> is an exp=
ression whose value is a temporary object. That temporary object is destroy=
ed at the end of the full expression <font face=3D"courier new, monospace">=
<div class=3D"prettyprint" style=3D"border: 1px solid rgb(187, 187, 187); w=
ord-wrap: break-word; background-color: rgb(250, 250, 250);"><code class=3D=
"prettyprint"><div class=3D"subprettyprint"><span style=3D"color: #000;" cl=
ass=3D"styled-by-prettify">function_ref</span><span style=3D"color: #660;" =
class=3D"styled-by-prettify">&lt;</span><span style=3D"color: #008;" class=
=3D"styled-by-prettify">int</span><span style=3D"color: #660;" class=3D"sty=
led-by-prettify">()&gt;</span><span style=3D"color: #000;" class=3D"styled-=
by-prettify"> f_ref </span><span style=3D"color: #660;" class=3D"styled-by-=
prettify">=3D</span><span style=3D"color: #000;" class=3D"styled-by-prettif=
y"> </span><span style=3D"color: #660;" class=3D"styled-by-prettify">[&amp;=
]()</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span=
><span style=3D"color: #660;" class=3D"styled-by-prettify">{</span><span st=
yle=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"co=
lor: #008;" class=3D"styled-by-prettify">return</span><span style=3D"color:=
 #000;" class=3D"styled-by-prettify"> non_const_var</span><span style=3D"co=
lor: #660;" class=3D"styled-by-prettify">;};</span></div></code></div></fon=
t></div><div><font face=3D"arial, sans-serif">Using the reference stored in=
 f_ref to access that object after the end of its lifetime results in undef=
ined behavior.</font></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/ee95d8af-e8e9-47bc-9d61-d95551aac4f3%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/ee95d8af-e8e9-47bc-9d61-d95551aac4f3=
%40isocpp.org</a>.<br />

------=_Part_3354_1922901637.1469974505991--

------=_Part_3353_1240093709.1469974505991--

.

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

Understood, thanks. Hence llvm::function_ref really is what it says. I.e.
don't use it beyond references to functions.

On 31 Jul 2016 16:15, "Casey Carter" <cartec69@gmail.com> wrote:

On Sunday, July 31, 2016 at 6:29:30 AM UTC-7, Carl Cook wrote:
>
> In the example below, I am not passing a function_ref as the return value,
> I am returning the result of the invocation of that function_ref, which I'd
> assumed would be safe (i.e. return an integer).
>
> However, it is the invocation that has failed, because the compiler has
> decided that the lambda can already be cleaned up (from what I can tell,
> looking at the disassembly).
>
> So, granted that the function_ref certainly doesn't copy callable objects,
> but I don't think it's useful for any lambda, unless that lambda is just
> used to invoke a function (as in the llvm example usage).
>
> On Friday, 15 July 2016 20:27:56 UTC+2, Richard Smith wrote:
>>
>> On Fri, Jul 15, 2016 at 2:12 AM, Carl Cook <carl...@gmail.com> wrote:
>>
>>> On Friday, 15 July 2016 02:35:42 UTC+2, Richard Smith wrote:
>>>>
>>>> llvm::function_ref doesn't capture anything, and is not supposed to --
>>>> it's a *non-owning* handle to a callable that outlives the handle.
>>>> (llvm::function_ref is to std::function as std::string_view is to
>>>> std::string.) This is a feature and a design goal of llvm::function_ref,
>>>> but I think it means it's addressing a fundamentally different problem than
>>>> the one you're tackling here (which seems to be essentially, "let me
>>>> control the size and alignment in std::function's small function
>>>> optimization"
>>>>
>>>
>>> Understood. What caught me out is that compilers can aggressively limit
>>> the scope of lambdas. Hence I believe the following is not legal usage:
>>>
>>> int non_const_var = 0xf;
>>> function_ref<int()> f_ref = [&]() { return non_const_var;};
>>> return f_ref();
>>>
>>
>> Right, it's exactly as broken as this:
>>
>> string g() {
>>   string_view s_v = string("blah blah");
>>   return s_v;
>> }
>>
>> In both cases, you've bound an object with reference semantics to a
>> (non-lifetime-extended) temporary object.
>>
>
[&]() { return non_const_var;}; is an expression whose value is a temporary
object. That temporary object is destroyed at the end of the full
expression
function_ref<int()> f_ref = [&]() { return non_const_var;};
Using the reference stored in f_ref to access that object after the end of
its lifetime results in undefined behavior.

--
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/vven2Om7Ha8/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/ee95d8af-e8e9-47bc-9d61-d95551aac4f3%40isocpp.org
<https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/ee95d8af-e8e9-47bc-9d61-d95551aac4f3%40isocpp.org?utm_medium=email&utm_source=footer>
..

--
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/CAGa0LWtm1z9Ysynmfa8L2G%3D7_aFn7YcSbpBHSYPDkuuR1qh4OA%40mail.gmail.com.

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

<p dir=3D"ltr">Understood, thanks. Hence llvm::function_ref really is what =
it says. I.e. don&#39;t use it beyond references to functions.</p>
<div class=3D"gmail_extra"><br><div class=3D"gmail_quote">On 31 Jul 2016 16=
:15, &quot;Casey Carter&quot; &lt;<a href=3D"mailto:cartec69@gmail.com">car=
tec69@gmail.com</a>&gt; wrote:<br type=3D"attribution"><blockquote class=3D=
"quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:=
1ex"><div dir=3D"ltr"><div class=3D"quoted-text">On Sunday, July 31, 2016 a=
t 6:29:30 AM UTC-7, Carl Cook 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">In the example below, I am not passing a function_ref as =
the return value, I am returning the result of the invocation of that funct=
ion_ref, which I&#39;d assumed would be safe (i.e. return an integer).<div>=
<br></div><div>However, it is the invocation that has failed, because the c=
ompiler has decided that the lambda can already be cleaned up (from what I =
can tell, looking at the disassembly).</div><div><br></div><div>So, granted=
 that the function_ref certainly doesn&#39;t copy callable objects, but I d=
on&#39;t think it&#39;s useful for any lambda, unless that lambda is just u=
sed to invoke a function (as in the llvm example usage).<br><br>On Friday, =
15 July 2016 20:27:56 UTC+2, Richard Smith  wrote:<blockquote class=3D"gmai=
l_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;pad=
ding-left:1ex"><div dir=3D"ltr"><div><div class=3D"gmail_quote">On Fri, Jul=
 15, 2016 at 2:12 AM, Carl Cook <span dir=3D"ltr">&lt;<a rel=3D"nofollow">c=
arl...@gmail.com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote"=
 style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><d=
iv dir=3D"ltr"><span>On Friday, 15 July 2016 02:35:42 UTC+2, Richard Smith =
 wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8e=
x;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div class=
=3D"gmail_quote"><div>llvm::function_ref doesn&#39;t capture anything, and =
is not supposed to -- it&#39;s a *non-owning* handle to a callable that out=
lives the handle. (llvm::function_ref is to std::function as std::string_vi=
ew is to std::string.) This is a feature and a design goal of llvm::functio=
n_ref, but I think it means it&#39;s addressing a fundamentally different p=
roblem than the one you&#39;re tackling here (which seems to be essentially=
, &quot;let me control the size and alignment in std::function&#39;s small =
function optimization&quot;</div></div></div></blockquote><div><br></div></=
span><div>Understood. What caught me out is that compilers can aggressively=
 limit the scope of lambdas. Hence I believe the following is not legal usa=
ge:</div><div><br></div><div><div style=3D"border:1px solid rgb(187,187,187=
);word-wrap:break-word;background-color:rgb(250,250,250)"><code><div><div>i=
nt non_const_var =3D 0xf;</div><div>function_ref&lt;int()&gt; f_ref =3D [&a=
mp;]() { return non_const_var;};</div><div>return f_ref();</div></div></cod=
e></div></div></div></blockquote><div><br></div><div>Right, it&#39;s exactl=
y as broken as this:</div><div><br></div><div>string g() {</div><div>=C2=A0=
 string_view s_v =3D string(&quot;blah blah&quot;);</div><div>=C2=A0 return=
 s_v;</div><div>}</div><div><br></div><div>In both cases, you&#39;ve bound =
an object with reference semantics to a (non-lifetime-extended) temporary o=
bject.</div></div></div></div></blockquote></div></div></blockquote><div><b=
r></div></div><div><font face=3D"courier new, monospace">[&amp;]() { return=
 non_const_var;};</font> is an expression whose value is a temporary object=
.. That temporary object is destroyed at the end of the full expression <div=
 class=3D"quoted-text"><font face=3D"courier new, monospace"><div style=3D"=
border:1px solid rgb(187,187,187);word-wrap:break-word;background-color:rgb=
(250,250,250)"><code><div><span style=3D"color:#000">function_ref</span><sp=
an style=3D"color:#660">&lt;</span><span style=3D"color:#008">int</span><sp=
an style=3D"color:#660">()&gt;</span><span style=3D"color:#000"> f_ref </sp=
an><span style=3D"color:#660">=3D</span><span style=3D"color:#000"> </span>=
<span style=3D"color:#660">[&amp;]()</span><span style=3D"color:#000"> </sp=
an><span style=3D"color:#660">{</span><span style=3D"color:#000"> </span><s=
pan style=3D"color:#008">return</span><span style=3D"color:#000"> non_const=
_var</span><span style=3D"color:#660">;};</span></div></code></div></font><=
/div></div><div><font face=3D"arial, sans-serif">Using the reference stored=
 in f_ref to access that object after the end of its lifetime results in un=
defined behavior.</font></div></div><div class=3D"quoted-text">

<p></p>

-- <br>
You received this message because you are subscribed to a topic in the Goog=
le Groups &quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this topic, visit <a href=3D"https://groups.google.com/=
a/isocpp.org/d/topic/std-proposals/vven2Om7Ha8/unsubscribe" target=3D"_blan=
k">https://groups.google.com/a/isocpp.org/d/topic/std-proposals/vven2Om7Ha8=
/unsubscribe</a>.<br>
To unsubscribe from this group and all its topics, send an email to <a href=
=3D"mailto:std-proposals+unsubscribe@isocpp.org" target=3D"_blank">std-prop=
osals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br></div>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/ee95d8af-e8e9-47bc-9d61-d95551aac4f3%=
40isocpp.org?utm_medium=3Demail&amp;utm_source=3Dfooter" target=3D"_blank">=
https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/ee95d8af-e8e9-=
47bc-9d61-d95551aac4f3%40isocpp.org</a>.<br>
</blockquote></div><br></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/CAGa0LWtm1z9Ysynmfa8L2G%3D7_aFn7YcSbp=
BHSYPDkuuR1qh4OA%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAGa0LWtm1z9Ysy=
nmfa8L2G%3D7_aFn7YcSbpBHSYPDkuuR1qh4OA%40mail.gmail.com</a>.<br />

--001a11443c786687530538ef4216--

.

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

On Sun, Jul 31, 2016 at 6:29 AM, Carl Cook <carl.cook@gmail.com> wrote:

> In the example below, I am not passing a function_ref as the return value,
> I am returning the result of the invocation of that function_ref, which I'd
> assumed would be safe (i.e. return an integer).
>
> However, it is the invocation that has failed, because the compiler has
> decided that the lambda can already be cleaned up (from what I can tell,
> looking at the disassembly).
>
> So, granted that the function_ref certainly doesn't copy callable objects,
> but I don't think it's useful for any lambda, unless that lambda is just
> used to invoke a function (as in the llvm example usage).
>

Actually, the above is exactly analogous to what happens in the string_view
case. Note that I'm returning a string, not a string_view.

In both cases, the problem happens in the construction of the
string_view/function_ref object: we're constructing an object that
represents a handle to another object, and the other object is a temporary
object that goes away at the end of the full-expression. And then on the
second line, we do something that tries to access the now-destroyed object
through the handle (in the string_view case, we construct a string from the
string_view, and in the function_ref case, we attempt to call the destroyed
closure object).

This is just how handle-like objects behave when bound to temporaries, and
not specific to string_view or function_ref.


> On Friday, 15 July 2016 20:27:56 UTC+2, Richard Smith wrote:
>>
>> On Fri, Jul 15, 2016 at 2:12 AM, Carl Cook <carl...@gmail.com> wrote:
>>
>>> On Friday, 15 July 2016 02:35:42 UTC+2, Richard Smith wrote:
>>>>
>>>> llvm::function_ref doesn't capture anything, and is not supposed to --
>>>> it's a *non-owning* handle to a callable that outlives the handle.
>>>> (llvm::function_ref is to std::function as std::string_view is to
>>>> std::string.) This is a feature and a design goal of llvm::function_ref,
>>>> but I think it means it's addressing a fundamentally different problem than
>>>> the one you're tackling here (which seems to be essentially, "let me
>>>> control the size and alignment in std::function's small function
>>>> optimization"
>>>>
>>>
>>> Understood. What caught me out is that compilers can aggressively limit
>>> the scope of lambdas. Hence I believe the following is not legal usage:
>>>
>>> int non_const_var = 0xf;
>>> function_ref<int()> f_ref = [&]() { return non_const_var;};
>>> return f_ref();
>>>
>>
>> Right, it's exactly as broken as this:
>>
>> string g() {
>>   string_view s_v = string("blah blah");
>>   return s_v;
>> }
>>
>> In both cases, you've bound an object with reference semantics to a
>> (non-lifetime-extended) temporary object.
>>
> --
> 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/c3bc751f-5586-44d5-ba6c-4c3d6708e4ad%40isocpp.org
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/c3bc751f-5586-44d5-ba6c-4c3d6708e4ad%40isocpp.org?utm_medium=email&utm_source=footer>
> .
>

--
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/CAOfiQq%3DK%2BGLh1GMBBzULYGNLUU4oeotAD0Lgn-S%3DwSv0hPWoog%40mail.gmail.com.

--001a114a6e3ac4e232053905057e
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 S=
un, Jul 31, 2016 at 6:29 AM, Carl Cook <span dir=3D"ltr">&lt;<a href=3D"mai=
lto:carl.cook@gmail.com" target=3D"_blank">carl.cook@gmail.com</a>&gt;</spa=
n> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;b=
order-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">In the example=
 below, I am not passing a function_ref as the return value, I am returning=
 the result of the invocation of that function_ref, which I&#39;d assumed w=
ould be safe (i.e. return an integer).<div><br></div><div>However, it is th=
e invocation that has failed, because the compiler has decided that the lam=
bda can already be cleaned up (from what I can tell, looking at the disasse=
mbly).</div><div><br></div><div>So, granted that the function_ref certainly=
 doesn&#39;t copy callable objects, but I don&#39;t think it&#39;s useful f=
or any lambda, unless that lambda is just used to invoke a function (as in =
the llvm example usage).<br></div></div></blockquote><div><br></div><div>Ac=
tually, the above is exactly analogous to what happens in the string_view c=
ase. Note that I&#39;m returning a string, not a string_view.</div><div><br=
></div><div>In both cases, the problem happens in the construction of the s=
tring_view/function_ref object: we&#39;re constructing an object that repre=
sents a handle to another object, and the other object is a temporary objec=
t that goes away at the end of the full-expression. And then on the second =
line, we do something that tries to access the now-destroyed object through=
 the handle (in the string_view case, we construct a string from the string=
_view, and in the function_ref case, we attempt to call the destroyed closu=
re object).</div><div><br></div><div>This is just how handle-like objects b=
ehave when bound to temporaries, and not specific to string_view or functio=
n_ref.</div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"mar=
gin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr=
"><div>On Friday, 15 July 2016 20:27:56 UTC+2, Richard Smith  wrote:<span c=
lass=3D""><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"><div><di=
v class=3D"gmail_quote">On Fri, Jul 15, 2016 at 2:12 AM, Carl Cook <span di=
r=3D"ltr">&lt;<a rel=3D"nofollow">carl...@gmail.com</a>&gt;</span> wrote:<b=
r><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:=
1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><span>On Friday, 15 July =
2016 02:35:42 UTC+2, Richard Smith  wrote:<blockquote class=3D"gmail_quote"=
 style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-lef=
t:1ex"><div dir=3D"ltr"><div class=3D"gmail_quote"><div>llvm::function_ref =
doesn&#39;t capture anything, and is not supposed to -- it&#39;s a *non-own=
ing* handle to a callable that outlives the handle. (llvm::function_ref is =
to std::function as std::string_view is to std::string.) This is a feature =
and a design goal of llvm::function_ref, but I think it means it&#39;s addr=
essing a fundamentally different problem than the one you&#39;re tackling h=
ere (which seems to be essentially, &quot;let me control the size and align=
ment in std::function&#39;s small function optimization&quot;</div></div></=
div></blockquote><div><br></div></span><div>Understood. What caught me out =
is that compilers can aggressively limit the scope of lambdas. Hence I beli=
eve the following is not legal usage:</div><div><br></div><div><div style=
=3D"border:1px solid rgb(187,187,187);word-wrap:break-word;background-color=
:rgb(250,250,250)"><code><div><div>int non_const_var =3D 0xf;</div><div>fun=
ction_ref&lt;int()&gt; f_ref =3D [&amp;]() { return non_const_var;};</div><=
div>return f_ref();</div></div></code></div></div></div></blockquote><div><=
br></div><div>Right, it&#39;s exactly as broken as this:</div><div><br></di=
v><div>string g() {</div><div>=C2=A0 string_view s_v =3D string(&quot;blah =
blah&quot;);</div><div>=C2=A0 return s_v;</div><div>}</div><div><br></div><=
div>In both cases, you&#39;ve bound an object with reference semantics to a=
 (non-lifetime-extended) temporary object.</div></div></div></div>
</blockquote></span></div></div>

<p></p>

-- <br><span class=3D"">
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" target=3D"_=
blank">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br></span>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/c3bc751f-5586-44d5-ba6c-4c3d6708e4ad%=
40isocpp.org?utm_medium=3Demail&amp;utm_source=3Dfooter" target=3D"_blank">=
https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/c3bc751f-5586-=
44d5-ba6c-4c3d6708e4ad%40isocpp.org</a>.<br>
</blockquote></div><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/CAOfiQq%3DK%2BGLh1GMBBzULYGNLUU4oeotA=
D0Lgn-S%3DwSv0hPWoog%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfoote=
r">https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAOfiQq%3DK=
%2BGLh1GMBBzULYGNLUU4oeotAD0Lgn-S%3DwSv0hPWoog%40mail.gmail.com</a>.<br />

--001a114a6e3ac4e232053905057e--

.

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

I didn't spot that you are indeed returning a string. My mistake. Thanks,
yes now I see that your example holds perfectly.

On 1 Aug 2016 18:23, "Richard Smith" <richard@metafoo.co.uk> wrote:

> On Sun, Jul 31, 2016 at 6:29 AM, Carl Cook <carl.cook@gmail.com> wrote:
>
>> In the example below, I am not passing a function_ref as the return
>> value, I am returning the result of the invocation of that function_ref,
>> which I'd assumed would be safe (i.e. return an integer).
>>
>> However, it is the invocation that has failed, because the compiler has
>> decided that the lambda can already be cleaned up (from what I can tell,
>> looking at the disassembly).
>>
>> So, granted that the function_ref certainly doesn't copy callable
>> objects, but I don't think it's useful for any lambda, unless that lambda
>> is just used to invoke a function (as in the llvm example usage).
>>
>
> Actually, the above is exactly analogous to what happens in the
> string_view case. Note that I'm returning a string, not a string_view.
>
> In both cases, the problem happens in the construction of the
> string_view/function_ref object: we're constructing an object that
> represents a handle to another object, and the other object is a temporary
> object that goes away at the end of the full-expression. And then on the
> second line, we do something that tries to access the now-destroyed object
> through the handle (in the string_view case, we construct a string from the
> string_view, and in the function_ref case, we attempt to call the destroyed
> closure object).
>
> This is just how handle-like objects behave when bound to temporaries, and
> not specific to string_view or function_ref.
>
>
>> On Friday, 15 July 2016 20:27:56 UTC+2, Richard Smith wrote:
>>>
>>> On Fri, Jul 15, 2016 at 2:12 AM, Carl Cook <carl...@gmail.com> wrote:
>>>
>>>> On Friday, 15 July 2016 02:35:42 UTC+2, Richard Smith wrote:
>>>>>
>>>>> llvm::function_ref doesn't capture anything, and is not supposed to --
>>>>> it's a *non-owning* handle to a callable that outlives the handle.
>>>>> (llvm::function_ref is to std::function as std::string_view is to
>>>>> std::string.) This is a feature and a design goal of llvm::function_ref,
>>>>> but I think it means it's addressing a fundamentally different problem than
>>>>> the one you're tackling here (which seems to be essentially, "let me
>>>>> control the size and alignment in std::function's small function
>>>>> optimization"
>>>>>
>>>>
>>>> Understood. What caught me out is that compilers can aggressively limit
>>>> the scope of lambdas. Hence I believe the following is not legal usage:
>>>>
>>>> int non_const_var = 0xf;
>>>> function_ref<int()> f_ref = [&]() { return non_const_var;};
>>>> return f_ref();
>>>>
>>>
>>> Right, it's exactly as broken as this:
>>>
>>> string g() {
>>>   string_view s_v = string("blah blah");
>>>   return s_v;
>>> }
>>>
>>> In both cases, you've bound an object with reference semantics to a
>>> (non-lifetime-extended) temporary object.
>>>
>> --
>> 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/c3bc751f-5586-44d5-ba6c-4c3d6708e4ad%40isocpp.org
>> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/c3bc751f-5586-44d5-ba6c-4c3d6708e4ad%40isocpp.org?utm_medium=email&utm_source=footer>
>> .
>>
>
> --
> 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/vven2Om7Ha8/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/CAOfiQq%3DK%2BGLh1GMBBzULYGNLUU4oeotAD0Lgn-S%3DwSv0hPWoog%40mail.gmail.com
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAOfiQq%3DK%2BGLh1GMBBzULYGNLUU4oeotAD0Lgn-S%3DwSv0hPWoog%40mail.gmail.com?utm_medium=email&utm_source=footer>
> .
>

--
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/CAGa0LWsUjCP5j8ra_F1mZczRXjdwgkhhFdOLDYS7Jm982v4iyQ%40mail.gmail.com.

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

<p dir=3D"ltr">I didn&#39;t spot that you are indeed returning a string. My=
 mistake. Thanks, yes now I see that your example holds perfectly.</p>
<div class=3D"gmail_extra"><br><div class=3D"gmail_quote">On 1 Aug 2016 18:=
23, &quot;Richard Smith&quot; &lt;<a href=3D"mailto:richard@metafoo.co.uk">=
richard@metafoo.co.uk</a>&gt; wrote:<br type=3D"attribution"><blockquote cl=
ass=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;p=
adding-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"=
gmail_quote">On Sun, Jul 31, 2016 at 6:29 AM, Carl Cook <span dir=3D"ltr">&=
lt;<a href=3D"mailto:carl.cook@gmail.com" target=3D"_blank">carl.cook@gmail=
..com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"ma=
rgin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"lt=
r">In the example below, I am not passing a function_ref as the return valu=
e, I am returning the result of the invocation of that function_ref, which =
I&#39;d assumed would be safe (i.e. return an integer).<div><br></div><div>=
However, it is the invocation that has failed, because the compiler has dec=
ided that the lambda can already be cleaned up (from what I can tell, looki=
ng at the disassembly).</div><div><br></div><div>So, granted that the funct=
ion_ref certainly doesn&#39;t copy callable objects, but I don&#39;t think =
it&#39;s useful for any lambda, unless that lambda is just used to invoke a=
 function (as in the llvm example usage).<br></div></div></blockquote><div>=
<br></div><div>Actually, the above is exactly analogous to what happens in =
the string_view case. Note that I&#39;m returning a string, not a string_vi=
ew.</div><div><br></div><div>In both cases, the problem happens in the cons=
truction of the string_view/function_ref object: we&#39;re constructing an =
object that represents a handle to another object, and the other object is =
a temporary object that goes away at the end of the full-expression. And th=
en on the second line, we do something that tries to access the now-destroy=
ed object through the handle (in the string_view case, we construct a strin=
g from the string_view, and in the function_ref case, we attempt to call th=
e destroyed closure object).</div><div><br></div><div>This is just how hand=
le-like objects behave when bound to temporaries, and not specific to strin=
g_view or function_ref.</div><div>=C2=A0</div><blockquote class=3D"gmail_qu=
ote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex=
"><div dir=3D"ltr"><div>On Friday, 15 July 2016 20:27:56 UTC+2, Richard Smi=
th  wrote:<span><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"><d=
iv><div class=3D"gmail_quote">On Fri, Jul 15, 2016 at 2:12 AM, Carl Cook <s=
pan dir=3D"ltr">&lt;<a rel=3D"nofollow">carl...@gmail.com</a>&gt;</span> wr=
ote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border=
-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><span>On Friday, 15=
 July 2016 02:35:42 UTC+2, Richard Smith  wrote:<blockquote class=3D"gmail_=
quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;paddi=
ng-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_quote"><div>llvm::functio=
n_ref doesn&#39;t capture anything, and is not supposed to -- it&#39;s a *n=
on-owning* handle to a callable that outlives the handle. (llvm::function_r=
ef is to std::function as std::string_view is to std::string.) This is a fe=
ature and a design goal of llvm::function_ref, but I think it means it&#39;=
s addressing a fundamentally different problem than the one you&#39;re tack=
ling here (which seems to be essentially, &quot;let me control the size and=
 alignment in std::function&#39;s small function optimization&quot;</div></=
div></div></blockquote><div><br></div></span><div>Understood. What caught m=
e out is that compilers can aggressively limit the scope of lambdas. Hence =
I believe the following is not legal usage:</div><div><br></div><div><div s=
tyle=3D"border:1px solid rgb(187,187,187);word-wrap:break-word;background-c=
olor:rgb(250,250,250)"><code><div><div>int non_const_var =3D 0xf;</div><div=
>function_ref&lt;int()&gt; f_ref =3D [&amp;]() { return non_const_var;};</d=
iv><div>return f_ref();</div></div></code></div></div></div></blockquote><d=
iv><br></div><div>Right, it&#39;s exactly as broken as this:</div><div><br>=
</div><div>string g() {</div><div>=C2=A0 string_view s_v =3D string(&quot;b=
lah blah&quot;);</div><div>=C2=A0 return s_v;</div><div>}</div><div><br></d=
iv><div>In both cases, you&#39;ve bound an object with reference semantics =
to a (non-lifetime-extended) temporary object.</div></div></div></div>
</blockquote></span></div></div>

<p></p>

-- <br><span>
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" target=3D"_=
blank">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br></span>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/c3bc751f-5586-44d5-ba6c-4c3d6708e4ad%=
40isocpp.org?utm_medium=3Demail&amp;utm_source=3Dfooter" target=3D"_blank">=
https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/c3bc751f-5586-=
44d5-ba6c-4c3d6708e4ad%40isocpp.org</a>.<br>
</blockquote></div><br></div></div>

<p></p>

-- <br>
You received this message because you are subscribed to a topic in the Goog=
le Groups &quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this topic, visit <a href=3D"https://groups.google.com/=
a/isocpp.org/d/topic/std-proposals/vven2Om7Ha8/unsubscribe" target=3D"_blan=
k">https://groups.google.com/a/isocpp.org/d/topic/std-proposals/vven2Om7Ha8=
/unsubscribe</a>.<br>
To unsubscribe from this group and all its topics, send an email to <a href=
=3D"mailto:std-proposals+unsubscribe@isocpp.org" target=3D"_blank">std-prop=
osals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">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/CAOfiQq%3DK%2BGLh1GMBBzULYGNLUU4oeotA=
D0Lgn-S%3DwSv0hPWoog%40mail.gmail.com?utm_medium=3Demail&amp;utm_source=3Df=
ooter" target=3D"_blank">https://groups.google.com/a/isocpp.org/d/msgid/std=
-proposals/CAOfiQq%3DK%2BGLh1GMBBzULYGNLUU4oeotAD0Lgn-S%3DwSv0hPWoog%40mail=
..gmail.com</a>.<br>
</blockquote></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/CAGa0LWsUjCP5j8ra_F1mZczRXjdwgkhhFdOL=
DYS7Jm982v4iyQ%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">htt=
ps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAGa0LWsUjCP5j8ra=
_F1mZczRXjdwgkhhFdOLDYS7Jm982v4iyQ%40mail.gmail.com</a>.<br />

--001a1145b52c72ec8e0539051045--

.

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

On Sun, Jul 31, 2016 at 9:53 AM, Nicol Bolas <jmckesson@gmail.com> wrote:

>
>
> On Friday, July 15, 2016 at 3:13:58 AM UTC-4, Nevin ":-)" Liber wrote:
>>
>> On 14 July 2016 at 23:30, Nicol Bolas <jmck...@gmail.com> wrote:
>>
>>> The use case of "someone used `std::function` in an interface, but I use
>>> `std::inplace_function` internally, and I need to talk to their code."
>>> Right now, `std::function` is how lots of C++ code takes callbacks, and for
>>> good reason. But if I've wrapped some function in an `inplace_function`, I
>>> still need to be able to talk to them.
>>>
>>
>> Maybe std::function is the wrong vocabulary type for interfaces, just
>> like std::string is the wrong vocabulary type for interfaces, hence we will
>> have std::string_view.  Having something like llvm::function_ref that
>> Richard Smith described earlier might be a better fit (and LEWG might ask
>> Carl to add such a beast to his proposal).
>>
>
> That's a really good analogy. I think the principle concern for the user
> is this. `string_view` is a great interface type because you can use it to
> construct pretty much any kind of string you like. It isn't limited to just
> `std::string` construction.
>

I don't think that's why string_view is great.  Rather, string_view is
great because you probably don't need to create anything at all.  You
probably just need to *use* the characters, not keep them.  ie a
file_open(string_view) could (in theory at least) just use the characters
in the string_view to open the file, it doesn't need to create a string of
any kind to keep around. (unfortunately, in real life the OS probably needs
a null-terminated string).


> Would a hypothetical `function_view` have an interface that could be used
> to construct any kind of function wrapper? That is, how could it expose the
> actual type of the callable in such a way that someone could copy it out?
>
>
Same with function vs function_ref.  In most uses, you want to *call* the
function, not keep it or a copy of it.  Like sort(container, my_less).  You
want to call my_less, not keep it for later.

Tony


> Though we could probably get away with just allowing it to be converted to
> a `function`. Or rather more specifically, allowing `function` to be
> constructed from a `function_view`.
>
> --
> 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/892618b7-19a9-4950-b552-ea5d5185362f%40isocpp.org
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/892618b7-19a9-4950-b552-ea5d5185362f%40isocpp.org?utm_medium=email&utm_source=footer>
> .
>



--
Be seeing you,
Tony

--
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/CAOHCbivQ9cj%3DiMu9g1_AZha6Z27U%3DmDv%2BkdKxj%3DQqSw2Sp3zFw%40mail.gmail.com.

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

<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><div class=3D"gmail_quo=
te">On Sun, Jul 31, 2016 at 9:53 AM, Nicol Bolas <span dir=3D"ltr">&lt;<a h=
ref=3D"mailto:jmckesson@gmail.com" target=3D"_blank">jmckesson@gmail.com</a=
>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 =
0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><br>=
<br>On Friday, July 15, 2016 at 3:13:58 AM UTC-4, Nevin &quot;:-)&quot; Lib=
er wrote:<span class=3D""><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"><div>On 14 July 2016 at 23:30, Nicol Bolas <span dir=3D"ltr">&lt;<=
a rel=3D"nofollow">jmck...@gmail.com</a>&gt;</span> wrote:<br><div class=3D=
"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;=
border-left:1px #ccc solid;padding-left:1ex"><div>The use case of &quot;som=
eone used `std::function` in an interface, but I use `std::inplace_function=
` internally, and I need to talk to their code.&quot; Right now, `std::func=
tion` is how lots of C++ code takes callbacks, and for good reason. But if =
I&#39;ve wrapped some function in an `inplace_function`, I still need to be=
 able to talk to them.<br></div></blockquote></div><br>Maybe std::function =
is the wrong vocabulary type for interfaces, just like std::string is the w=
rong vocabulary type for interfaces, hence we will have std::string_view.=
=C2=A0 Having something like llvm::function_ref that Richard Smith describe=
d earlier might be a better fit (and LEWG might ask Carl to add such a beas=
t to his proposal).<br></div></div></blockquote></span><div><br>That&#39;s =
a really good analogy. I think the principle concern for the user is this. =
`string_view` is a great interface type because you can use it to construct=
 pretty much any kind of string you like. It isn&#39;t limited to just `std=
::string` construction. </div></div></blockquote><div><br></div><div>I don&=
#39;t think that&#39;s why string_view is great.=C2=A0 Rather, string_view =
is great because you probably don&#39;t need to create anything at all.=C2=
=A0 You probably just need to *use* the characters, not keep them.=C2=A0 ie=
 a file_open(string_view) could (in theory at least) just use the character=
s in the string_view to open the file, it doesn&#39;t need to create a stri=
ng of any kind to keep around. (unfortunately, in real life the OS probably=
 needs a null-terminated string).<br>=C2=A0<br></div><blockquote class=3D"g=
mail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-l=
eft:1ex"><div dir=3D"ltr"><div>Would a hypothetical `function_view` have an=
 interface that could be used to construct any kind of function wrapper? Th=
at is, how could it expose the actual type of the callable in such a way th=
at someone could copy it out?<br><br></div></div></blockquote><div><br></di=
v><div>Same with function vs function_ref.=C2=A0 In most uses, you want to =
*call* the function, not keep it or a copy of it.=C2=A0 Like sort(container=
, my_less).=C2=A0 You want to call my_less, not keep it for later.<br><br><=
/div><div>Tony<br></div><div>=C2=A0<br></div><blockquote class=3D"gmail_quo=
te" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"=
><div dir=3D"ltr"><div>Though we could probably get away with just allowing=
 it to be converted to a `function`. Or rather more specifically, allowing =
`function` to be constructed from a `function_view`.<br></div></div><span c=
lass=3D"">

<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" target=3D"_=
blank">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br></span>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/892618b7-19a9-4950-b552-ea5d5185362f%=
40isocpp.org?utm_medium=3Demail&amp;utm_source=3Dfooter" target=3D"_blank">=
https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/892618b7-19a9-=
4950-b552-ea5d5185362f%40isocpp.org</a>.<br>
</blockquote></div><br><br clear=3D"all"><br>-- <br><div class=3D"gmail_sig=
nature" data-smartmail=3D"gmail_signature"><div dir=3D"ltr"><div>Be seeing =
you,<br></div>Tony<br></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/CAOHCbivQ9cj%3DiMu9g1_AZha6Z27U%3DmDv=
%2BkdKxj%3DQqSw2Sp3zFw%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfoo=
ter">https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAOHCbivQ=
9cj%3DiMu9g1_AZha6Z27U%3DmDv%2BkdKxj%3DQqSw2Sp3zFw%40mail.gmail.com</a>.<br=
 />

--001a114b703a20706005390578c0--

.

------=_Part_3369_1343443013.1470072523092
Content-Type: multipart/alternative;
 boundary="----=_Part_3370_602717089.1470072523092"

------=_Part_3370_602717089.1470072523092
Content-Type: text/plain; charset=UTF-8

On Monday, August 1, 2016 at 12:55:38 PM UTC-4, Tony V E wrote:
>
> On Sun, Jul 31, 2016 at 9:53 AM, Nicol Bolas <jmck...@gmail.com
> <javascript:>> wrote:
>
>> On Friday, July 15, 2016 at 3:13:58 AM UTC-4, Nevin ":-)" Liber wrote:
>>>
>>> On 14 July 2016 at 23:30, Nicol Bolas <jmck...@gmail.com> wrote:
>>>
>>>> The use case of "someone used `std::function` in an interface, but I
>>>> use `std::inplace_function` internally, and I need to talk to their code."
>>>> Right now, `std::function` is how lots of C++ code takes callbacks, and for
>>>> good reason. But if I've wrapped some function in an `inplace_function`, I
>>>> still need to be able to talk to them.
>>>>
>>>
>>> Maybe std::function is the wrong vocabulary type for interfaces, just
>>> like std::string is the wrong vocabulary type for interfaces, hence we will
>>> have std::string_view.  Having something like llvm::function_ref that
>>> Richard Smith described earlier might be a better fit (and LEWG might ask
>>> Carl to add such a beast to his proposal).
>>>
>>
>> That's a really good analogy. I think the principle concern for the user
>> is this. `string_view` is a great interface type because you can use it to
>> construct pretty much any kind of string you like. It isn't limited to just
>> `std::string` construction.
>>
>
> I don't think that's why string_view is great.  Rather, string_view is
> great because you probably don't need to create anything at all.  You
> probably just need to *use* the characters, not keep them.  ie a
> file_open(string_view) could (in theory at least) just use the characters
> in the string_view to open the file, it doesn't need to create a string of
> any kind to keep around. (unfortunately, in real life the OS probably needs
> a null-terminated string).
>

Which is why it's a good thing that `string_view` makes it easy to
construct a null-terminated string from itself, yes? It makes it easy to
support those APIs that have needs that `string_view` doesn't fulfill.

Admittedly, the argument isn't as compelling for `function_view`, since
copying functions is very different from copying strings. So if your API
needed to store the function long-term, it's more likely that you'd use
either `std::function` or a specialized type of your own devising in the
interface.

However, that reminds me of something. I recall seeing some proposal or
somesuch about an alteration of `string_view` that would know if it were
null-terminated or not.

--
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/1cded9b7-eb8b-4618-8fb6-06e8e24cd87b%40isocpp.org.

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

<div dir=3D"ltr">On Monday, August 1, 2016 at 12:55:38 PM UTC-4, Tony V E w=
rote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8e=
x;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div><di=
v class=3D"gmail_quote">On Sun, Jul 31, 2016 at 9:53 AM, Nicol Bolas <span =
dir=3D"ltr">&lt;<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-ma=
ilto=3D"86fpXcO0BgAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;java=
script:&#39;;return true;" onclick=3D"this.href=3D&#39;javascript:&#39;;ret=
urn true;">jmck...@gmail.com</a>&gt;</span> wrote:<br><blockquote class=3D"=
gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-=
left:1ex"><div dir=3D"ltr">On Friday, July 15, 2016 at 3:13:58 AM UTC-4, Ne=
vin &quot;:-)&quot; Liber wrote:<span><blockquote class=3D"gmail_quote" sty=
le=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1e=
x"><div dir=3D"ltr"><div>On 14 July 2016 at 23:30, Nicol Bolas <span dir=3D=
"ltr">&lt;<a rel=3D"nofollow">jmck...@gmail.com</a>&gt;</span> wrote:<br><d=
iv class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margin:=
0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>The use case o=
f &quot;someone used `std::function` in an interface, but I use `std::inpla=
ce_function` internally, and I need to talk to their code.&quot; Right now,=
 `std::function` is how lots of C++ code takes callbacks, and for good reas=
on. But if I&#39;ve wrapped some function in an `inplace_function`, I still=
 need to be able to talk to them.<br></div></blockquote></div><br>Maybe std=
::function is the wrong vocabulary type for interfaces, just like std::stri=
ng is the wrong vocabulary type for interfaces, hence we will have std::str=
ing_view.=C2=A0 Having something like llvm::function_ref that Richard Smith=
 described earlier might be a better fit (and LEWG might ask Carl to add su=
ch a beast to his proposal).<br></div></div></blockquote></span><div><br>Th=
at&#39;s a really good analogy. I think the principle concern for the user =
is this. `string_view` is a great interface type because you can use it to =
construct pretty much any kind of string you like. It isn&#39;t limited to =
just `std::string` construction. </div></div></blockquote><div><br></div><d=
iv>I don&#39;t think that&#39;s why string_view is great.=C2=A0 Rather, str=
ing_view is great because you probably don&#39;t need to create anything at=
 all.=C2=A0 You probably just need to *use* the characters, not keep them.=
=C2=A0 ie a file_open(string_view) could (in theory at least) just use the =
characters in the string_view to open the file, it doesn&#39;t need to crea=
te a string of any kind to keep around. (unfortunately, in real life the OS=
 probably needs a null-terminated string).<br></div></div></div></div></blo=
ckquote><div><br>Which is why it&#39;s a good thing that `string_view` make=
s it easy to construct a null-terminated string from itself, yes? It makes =
it easy to support those APIs that have needs that `string_view` doesn&#39;=
t fulfill.<br><br>Admittedly, the argument isn&#39;t as compelling for `fun=
ction_view`, since copying functions is very different from copying strings=
.. So if your API needed to store the function long-term, it&#39;s more like=
ly that you&#39;d use either `std::function` or a specialized type of your =
own devising in the interface.<br><br>However, that reminds me of something=
.. I recall seeing some proposal or somesuch about an alteration of `string_=
view` that would know if it were null-terminated or not.<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/1cded9b7-eb8b-4618-8fb6-06e8e24cd87b%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/1cded9b7-eb8b-4618-8fb6-06e8e24cd87b=
%40isocpp.org</a>.<br />

------=_Part_3370_602717089.1470072523092--

------=_Part_3369_1343443013.1470072523092--

.

------=_Part_21_1431069579.1474396401357
Content-Type: multipart/alternative;
 boundary="----=_Part_22_345748464.1474396401358"

------=_Part_22_345748464.1474396401358
Content-Type: text/plain; charset=UTF-8

I am all for non-allocating function objects - vast majorities of my
lambdas are small enough to be "stack-only", but bigger then the
std::function SOO threshold!

*But isn't it time to think for first-class 'callable' type?*

It is somewhat weird, we have first class, wildly-used, lambdas, but no
native way to store and pass them around - we have to use 10+ years old
container. It's like a new car with second-hand tires.

And we also have no clean and efficient way to define an interface which
accepts a callable - we either have to use templates (not clean, though
Concepts will improve that) or use std::function and not be as efficient
(and still not all that clean).



--
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/1dce887f-b468-4978-9466-a9630cfc2671%40isocpp.org.

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

<div dir=3D"ltr">I am all for non-allocating function objects - vast majori=
ties of my lambdas are small enough to be &quot;stack-only&quot;, but bigge=
r then the std::function SOO threshold!<div><br></div><div><b>But isn&#39;t=
 it time to think for first-class &#39;callable&#39; type?</b>=C2=A0</div><=
div><br></div><div>It is somewhat weird, we have first class, wildly-used, =
lambdas, but no native way to store and pass them around - we have to use 1=
0+ years old container. It&#39;s like a new car with second-hand tires.=C2=
=A0</div><div><br></div><div>And we also have no clean and efficient way to=
 define an interface which accepts a callable - we either have to use templ=
ates (not clean, though Concepts will improve that) or use std::function an=
d not be as efficient (and still not all that clean).</div><div>=C2=A0</div=
><div><br></div><div><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/1dce887f-b468-4978-9466-a9630cfc2671%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/1dce887f-b468-4978-9466-a9630cfc2671=
%40isocpp.org</a>.<br />

------=_Part_22_345748464.1474396401358--

------=_Part_21_1431069579.1474396401357--

.

--089e013c646a84981c053cf4b8de
Content-Type: text/plain; charset=UTF-8

On Tue, Sep 20, 2016 at 7:33 PM, <mihailnajdenov@gmail.com> wrote:

>
> *But isn't it time to think for first-class 'callable' type?*
>
> It is somewhat weird, we have first class, wildly-used, lambdas, but no
> native way to store and pass them around - we have to use 10+ years old
> container. It's like a new car with second-hand tires.
>
> And we also have no clean and efficient way to define an interface which
> accepts a callable - we either have to use templates (not clean, though
> Concepts will improve that) or use std::function and not be as efficient
> (and still not all that clean).
>
>
>
What's the alternative? How does one support arbitrary callable types, if
not by using templates? Which std::function is, just as much.

Of course, maybe you have an idea for some other way to do this. Then
you're in the right place to propose 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/CACGiwhFos3wukaQxPYDe%3Dw3nfWkdqKgH06_D-cQutc8FaKjXYQ%40mail.gmail.com.

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

<div dir=3D"ltr"><br><div class=3D"gmail_extra"><div class=3D"gmail_quote">=
On Tue, Sep 20, 2016 at 7:33 PM,  <span dir=3D"ltr">&lt;<a href=3D"mailto:m=
ihailnajdenov@gmail.com" target=3D"_blank">mihailnajdenov@gmail.com</a>&gt;=
</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .=
8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div><br>=
</div><div><b>But isn&#39;t it time to think for first-class &#39;callable&=
#39; type?</b>=C2=A0</div><div><br></div><div>It is somewhat weird, we have=
 first class, wildly-used, lambdas, but no native way to store and pass the=
m around - we have to use 10+ years old container. It&#39;s like a new car =
with second-hand tires.=C2=A0</div><div><br></div><div>And we also have no =
clean and efficient way to define an interface which accepts a callable - w=
e either have to use templates (not clean, though Concepts will improve tha=
t) or use std::function and not be as efficient (and still not all that cle=
an).</div><div>=C2=A0</div><br></div></blockquote><div><br></div><div>What&=
#39;s the alternative? How does one support arbitrary callable types, if no=
t by using templates? Which std::function is, just as much.<br><br></div><d=
iv>Of course, maybe you have an idea for some other way to do this. Then yo=
u&#39;re in the right place to propose it.<br><br></div><div>=C2=A0<br></di=
v></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/CACGiwhFos3wukaQxPYDe%3Dw3nfWkdqKgH06=
_D-cQutc8FaKjXYQ%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CACGiwhFos3wuka=
QxPYDe%3Dw3nfWkdqKgH06_D-cQutc8FaKjXYQ%40mail.gmail.com</a>.<br />

--089e013c646a84981c053cf4b8de--

.