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

Hi-

I'm at CppCon this week, so I'm afraid my feedback may be limited and
sketchy. With that disclaimer:

Section 1.1: In bullet 1, IIUC you're talking about unsafe access to shared
global state (e.g. std::cout). const qualification can't help with that,
but nor should it be expected to. If you're accessing shared global state
that's not thread-safe, you need to make sure everyone accessing it is
participating in a single synchronization mechanism. Leaving aside the
wording of [res.on.data.races], which nobody is happy with, the operative
principle here is that for sane objects, concurrent const accesses should
be safe, but a non-const access is unsafe if it's concurrent with any other
access (notice that the core language guarantees exactly that property for
scalar types). The examples involving std::cout violate that principle
because they access std::cout in a way that's potentially concurrent with
non-const accesses from other threads.

I don't understand what you're getting at with bullet 2. Bullets 3 and 4
miss the point a bit: most uses of std::function do not need
const_unsafe_fun. For the cases that do need it, const_unsafe_fun serves a
useful purpose of marking the unsafe operation as unsafe for future readers
and maintainers, in very much the same way that reinterpret_cast and
const_cast do (indeed, const_unsafe_fun is very much a disguised
const_cast).

FWIW I consider N4348 dead because of NB opposition, but as far as I can
tell, that opposition is based solely on the fact that it's a breaking
change, not on the other issues you raise.

I haven't had time to look at the rest of the paper; I'll follow up with
more comments if/when I can.

On Thu, Sep 24, 2015 at 1:55 AM, David Krauss <potswa@gmail.com> wrote:

> Another day, another draft. This is my fourth std::function-related
> proposal for Kona, and I saved the best for last.
>
> Abstract:
>
> std::function supports exactly one function signature at a time.
> Multiple, overloaded signatures have many uses: exposing several
> functionalities of a class, accessing data within the target object,
> discriminating between access as const, non-const, rvalue, lvalue, etc.
> Several third-party libraries address the niche, but the role of const is
> controversial and *ref-qualifiers* receive little attention. This
> proposal replaces std::function<R(P...)> with std::function<Sig...>,
> where Sig is any type allowed for member functions. The const dilemma is
> resolved without breakage. A quality prototype implementation is provided.
> PDF: bit.ly/qofun
> Implementation: https://github.com/potswa/cxx_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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

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

<div dir=3D"ltr">Hi-<div><br></div><div>I&#39;m at CppCon this week, so I&#=
39;m afraid my feedback may be limited and sketchy. With that disclaimer:</=
div><div><br></div><div>Section 1.1: In bullet 1, IIUC you&#39;re talking a=
bout unsafe access to shared global state (e.g. std::cout). const qualifica=
tion can&#39;t help with that, but nor should it be expected to. If you&#39=
;re accessing shared global state that&#39;s not thread-safe, you need to m=
ake sure everyone accessing it is participating in a single synchronization=
 mechanism. Leaving aside the wording of [res.on.data.races], which nobody =
is happy with, the operative principle here is that for sane objects, concu=
rrent const accesses should be safe, but a non-const access is unsafe if it=
&#39;s concurrent with any other access (notice that the core language guar=
antees exactly that property for scalar types). The examples involving std:=
:cout violate that principle because they access std::cout in a way that&#3=
9;s potentially concurrent with non-const accesses from other threads.</div=
><div><br></div><div>I don&#39;t understand what you&#39;re getting at with=
 bullet 2. Bullets 3 and 4 miss the point a bit: most uses of std::function=
 do not need const_unsafe_fun. For the cases that do need it, const_unsafe_=
fun serves a useful purpose of marking the unsafe operation as unsafe for f=
uture readers and maintainers, in very much the same way that reinterpret_c=
ast and const_cast do (indeed, const_unsafe_fun is very much a disguised co=
nst_cast).</div><div><br></div><div>FWIW I consider N4348 dead because of N=
B opposition, but as far as I can tell, that opposition is based solely on =
the fact that it&#39;s a breaking change, not on the other issues you raise=
..</div><div><br></div><div>I haven&#39;t had time to look at the rest of th=
e paper; I&#39;ll follow up with more comments if/when I can.</div></div><d=
iv class=3D"gmail_extra"><br><div class=3D"gmail_quote">On Thu, Sep 24, 201=
5 at 1:55 AM, David Krauss <span dir=3D"ltr">&lt;<a href=3D"mailto:potswa@g=
mail.com" target=3D"_blank">potswa@gmail.com</a>&gt;</span> wrote:<br><bloc=
kquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #cc=
c solid;padding-left:1ex"><div style=3D"word-wrap:break-word">Another day, =
another draft. This is my fourth=C2=A0<font face=3D"Courier">std::function<=
/font>-related proposal for Kona, and I saved the best for last.<div><br></=
div><div>Abstract:</div><div><p style=3D"margin:0px 0px 16px;font-family:Ti=
mes;font-size:13px"><span style=3D"font-size:12px;font-family:Courier;backg=
round-color:rgb(245,245,245)">std::function</span> supports exactly one fun=
ction signature at a time. Multiple, overloaded signatures have many uses: =
exposing several functionalities of a class, accessing data within the targ=
et object, discriminating between access as <span style=3D"font-size:12px;f=
ont-family:Courier;background-color:rgb(245,245,245)">const</span>, non-<sp=
an style=3D"font-size:12px;font-family:Courier;background-color:rgb(245,245=
,245)">const</span>, rvalue, lvalue, etc. Several third-party libraries add=
ress the niche, but the role of <span style=3D"font-size:12px;font-family:C=
ourier;background-color:rgb(245,245,245)">const</span> is controversial and=
 <i>ref-qualifiers</i> receive little attention. This proposal replaces <sp=
an style=3D"font-size:12px;font-family:Courier;background-color:rgb(245,245=
,245)">std::function&lt;R(P...)&gt;</span> with <span style=3D"font-size:12=
px;font-family:Courier;background-color:rgb(245,245,245)">std::function&lt;=
Sig...&gt;</span>, where <span style=3D"font-size:12px;font-family:Courier;=
background-color:rgb(245,245,245)">Sig</span> is any type allowed for membe=
r functions. The <span style=3D"font-size:12px;font-family:Courier;backgrou=
nd-color:rgb(245,245,245)">const</span> dilemma is resolved without breakag=
e. A quality prototype implementation is provided.<span style=3D"font-size:=
10px"><sup style=3D"font-size:10px"></sup></span></p></div><div>PDF: <a hre=
f=3D"http://bit.ly/qofun" target=3D"_blank">bit.ly/qofun</a></div><div>Impl=
ementation:=C2=A0<a href=3D"https://github.com/potswa/cxx_function" target=
=3D"_blank">https://github.com/potswa/cxx_function</a></div><div><br></div>=
</div></blockquote></div><br></div>

<p></p>

-- <br />
<br />
--- <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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--001a1143879c03fe1c052086fc94--

.

--Apple-Mail=_136C5658-70CD-4E01-B2C3-657732D4783B
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=UTF-8


> On 2015=E2=80=9309=E2=80=9325, at 7:56 AM, Geoffrey Romer <gromer@google.=
com> wrote:
>=20
> Hi-
>=20
> I'm at CppCon this week, so I'm afraid my feedback may be limited and ske=
tchy. With that disclaimer:
>=20
> Section 1.1: In bullet 1, IIUC you're talking about unsafe access to shar=
ed global state (e.g. std::cout). const qualification can't help with that,=
 but nor should it be expected to.

That=E2=80=99s the fundamental problem with [res.on.data.races]/2-3: it pre=
sumes reasonable expectations. But why take an =E2=80=9Cunexpected=E2=80=9D=
 interpretation of =C2=B63 without applying the same to =C2=B62?

To me, the obvious direction is to exempt callbacks. Perhaps it=E2=80=99s t=
ricky to get a precise definition of =E2=80=9Ccallback,=E2=80=9D but it=E2=
=80=99s worth a try. The problem should have a DR so LWG (maybe even CWG) c=
an consider, at least in a brief review, whether a simple solution exists.

> If you're accessing shared global state that's not thread-safe, you need =
to make sure everyone accessing it is participating in a single synchroniza=
tion mechanism. Leaving aside the wording of [res.on.data.races], which nob=
ody is happy with, the operative principle here is that for sane objects, c=
oncurrent const accesses should be safe, but a non-const access is unsafe i=
f it's concurrent with any other access (notice that the core language guar=
antees exactly that property for scalar types). The examples involving std:=
:cout violate that principle because they access std::cout in a way that's =
potentially concurrent with non-const accesses from other threads.

How is the const-safety (or thread-safety per =C2=B63) of calling a std::fu=
nction<void()> different from calling a std::reference_wrapper<nullary_ftor=
>? Both work like non-const-propagating pointers. (This is the gist of bull=
et 2.)

This argument is why I provided some extra motivation in =C2=A71. std::func=
tion<Sig> const is different because it may use const bytes for target allo=
cation, and although the object model is unclear about what really happens =
when one object lives inside another, it seems very unkosher to modify cons=
t object representation. (On the other hand, I never accounted for mutable,=
 but that still shouldn=E2=80=99t affect the programming model.)

> I don't understand what you're getting at with bullet 2. Bullets 3 and 4 =
miss the point a bit: most uses of std::function do not need const_unsafe_f=
un.

Do any intended use-cases of const_unsafe_fun, in fact, involve data races?=
 If so, then synchronization is the solution. (For thread-unaware objects t=
hat modify only internal state, which the user wishes to share, my sample c=
ritical_section template is the solution.) When it=E2=80=99s not about sync=
hronization, solutions besides const_cast should still be considered first.

> For the cases that do need it, const_unsafe_fun serves a useful purpose o=
f marking the unsafe operation as unsafe for future readers and maintainers=
, in very much the same way that reinterpret_cast and const_cast do (indeed=
, const_unsafe_fun is very much a disguised const_cast).

Should those be disguised? My proposal implements a const_cast automaticall=
y but refuses to let you ignore it. The name =E2=80=9Cconst_unsafe_fun=E2=
=80=9D might be intended as a red flag to future maintainers, but an unfami=
liar reader may just as likely suppose that it somehow adds safety or that =
it=E2=80=99s just stating an intrinsic fact. Readers tend not to want to be=
 maintainers.

> FWIW I consider N4348 dead because of NB opposition, but as far as I can =
tell, that opposition is based solely on the fact that it's a breaking chan=
ge, not on the other issues you raise.
>=20
> I haven't had time to look at the rest of the paper; I'll follow up with =
more comments if/when I can.

Thanks, it=E2=80=99s close to the deadline so I look forward to any feedbac=
k!

--=20

---=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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

--Apple-Mail=_136C5658-70CD-4E01-B2C3-657732D4783B
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=UTF-8

<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html charset=
=3Dutf-8"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-mode: s=
pace; -webkit-line-break: after-white-space;" class=3D""><br class=3D""><di=
v><blockquote type=3D"cite" class=3D""><div class=3D"">On 2015=E2=80=9309=
=E2=80=9325, at 7:56 AM, Geoffrey Romer &lt;<a href=3D"mailto:gromer@google=
..com" class=3D"">gromer@google.com</a>&gt; wrote:</div><br class=3D"Apple-i=
nterchange-newline"><div class=3D""><div dir=3D"ltr" class=3D"">Hi-<div cla=
ss=3D""><br class=3D""></div><div class=3D"">I'm at CppCon this week, so I'=
m afraid my feedback may be limited and sketchy. With that disclaimer:</div=
><div class=3D""><br class=3D""></div><div class=3D"">Section 1.1: In bulle=
t 1, IIUC you're talking about unsafe access to shared global state (e.g. s=
td::cout). const qualification can't help with that, but nor should it be e=
xpected to. </div></div></div></blockquote><div><br class=3D""></div><div>T=
hat=E2=80=99s the fundamental problem with [res.on.data.races]/2-3: it pres=
umes reasonable expectations. But why take an =E2=80=9Cunexpected=E2=80=9D =
interpretation of =C2=B63 without applying the same to =C2=B62?</div><div><=
br class=3D""></div><div>To me, the obvious direction is to exempt callback=
s. Perhaps it=E2=80=99s tricky to get a precise definition of =E2=80=9Ccall=
back,=E2=80=9D but it=E2=80=99s worth a try. The problem should have a DR s=
o LWG (maybe even CWG) can consider, at least in a brief review, whether a =
simple solution exists.</div><br class=3D""><blockquote type=3D"cite" class=
=3D""><div class=3D""><div dir=3D"ltr" class=3D""><div class=3D"">If you're=
 accessing shared global state that's not thread-safe, you need to make sur=
e everyone accessing it is participating in a single synchronization mechan=
ism. Leaving aside the wording of [res.on.data.races], which nobody is happ=
y with, the operative principle here is that for sane objects, concurrent c=
onst accesses should be safe, but a non-const access is unsafe if it's conc=
urrent with any other access (notice that the core language guarantees exac=
tly that property for scalar types). The examples involving std::cout viola=
te that principle because they access std::cout in a way that's potentially=
 concurrent with non-const accesses from other threads.</div><div class=3D"=
"></div></div></div></blockquote><div><br class=3D""></div><div>How is the =
const-safety (or thread-safety per =C2=B63) of calling a <font face=3D"Cour=
ier" class=3D"">std::function&lt;void()&gt;</font>&nbsp;different from call=
ing a <font face=3D"Courier" class=3D"">std::reference_wrapper&lt;nullary_f=
tor&gt;</font>? Both work like non-const-propagating pointers. (This is the=
 gist of bullet 2.)</div><div><br class=3D""></div><div>This argument is wh=
y I provided some extra motivation in =C2=A71. <font face=3D"Courier" class=
=3D"">std::function&lt;Sig&gt; const</font> is different because it may use=
&nbsp;<font face=3D"Courier" class=3D"">const</font> bytes for target alloc=
ation, and although the object model is unclear about what really happens w=
hen one object lives inside another, it seems very unkosher to modify <font=
 face=3D"Courier" class=3D"">const</font> object representation. (On the ot=
her hand, I never accounted for <font face=3D"Courier" class=3D"">mutable</=
font>, but that still shouldn=E2=80=99t affect the programming model.)</div=
><div><br class=3D""></div><blockquote type=3D"cite" class=3D""><div class=
=3D""><div dir=3D"ltr" class=3D""><div class=3D"">I don't understand what y=
ou're getting at with bullet 2. Bullets 3 and 4 miss the point a bit: most =
uses of std::function do not need const_unsafe_fun.</div></div></div></bloc=
kquote><div><br class=3D""></div><div>Do any intended use-cases of <font fa=
ce=3D"Courier" class=3D"">const_unsafe_fun</font>, in fact, involve data ra=
ces? If so, then synchronization is the solution. (For thread-unaware objec=
ts that modify only internal state, which the user wishes to share, my samp=
le <font face=3D"Courier" class=3D"">critical_section</font> template is th=
e solution.) When it=E2=80=99s not about synchronization, solutions besides=
 <font face=3D"Courier" class=3D"">const_cast</font> should still be consid=
ered first.</div><br class=3D""><blockquote type=3D"cite" class=3D""><div c=
lass=3D""><div dir=3D"ltr" class=3D""><div class=3D"">For the cases that do=
 need it, const_unsafe_fun serves a useful purpose of marking the unsafe op=
eration as unsafe for future readers and maintainers, in very much the same=
 way that reinterpret_cast and const_cast do (indeed, const_unsafe_fun is v=
ery much a disguised const_cast).</div><div class=3D""></div></div></div></=
blockquote><div><br class=3D""></div><div>Should those be disguised? My pro=
posal implements a <font face=3D"Courier" class=3D"">const_cast</font>&nbsp=
;automatically but refuses to let you ignore it. The name =E2=80=9C<font fa=
ce=3D"Courier" class=3D"">const_unsafe_fun</font>=E2=80=9D might be <i clas=
s=3D"">intended</i> as a red flag to future maintainers, but an unfamiliar =
reader may just as likely suppose that it somehow adds safety or that it=E2=
=80=99s just stating an intrinsic fact. Readers tend not to&nbsp;<i class=
=3D"">want</i>&nbsp;to be maintainers.</div><br class=3D""><blockquote type=
=3D"cite" class=3D""><div class=3D""><div dir=3D"ltr" class=3D""><div class=
=3D"">FWIW I consider N4348 dead because of NB opposition, but as far as I =
can tell, that opposition is based solely on the fact that it's a breaking =
change, not on the other issues you raise.</div><div class=3D""><br class=
=3D""></div><div class=3D"">I haven't had time to look at the rest of the p=
aper; I'll follow up with more comments if/when I can.</div></div></div></b=
lockquote></div><br class=3D""><div class=3D"">Thanks, it=E2=80=99s close t=
o the deadline so I look forward to any feedback!</div><div class=3D""><br =
class=3D""></div></body></html>

<p></p>

-- <br />
<br />
--- <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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--Apple-Mail=_136C5658-70CD-4E01-B2C3-657732D4783B--

.

--Apple-Mail=_243B46E4-53E7-4BF9-A654-35ADE9A1EC31
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=UTF-8


> On 2015=E2=80=9309=E2=80=9325, at 8:48 AM, David Krauss <potswa@gmail.com=
> wrote:
>=20
>> Section 1.1: In bullet 1, IIUC you're talking about unsafe access to sha=
red global state (e.g. std::cout). const qualification can't help with that=
, but nor should it be expected to.=20
>=20
> That=E2=80=99s the fundamental problem with [res.on.data.races]/2-3: it p=
resumes reasonable expectations. But why take an =E2=80=9Cunexpected=E2=80=
=9D interpretation of =C2=B63 without applying the same to =C2=B62?

(To be sure, the note in =C2=B64 specifically mentions shared global state,=
 so such interpretations don=E2=80=99t seem so unexpected.)

--=20

---=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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

--Apple-Mail=_243B46E4-53E7-4BF9-A654-35ADE9A1EC31
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=UTF-8

<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html charset=
=3Dutf-8"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-mode: s=
pace; -webkit-line-break: after-white-space;" class=3D""><br class=3D""><di=
v><blockquote type=3D"cite" class=3D""><div class=3D"">On 2015=E2=80=9309=
=E2=80=9325, at 8:48 AM, David Krauss &lt;<a href=3D"mailto:potswa@gmail.co=
m" class=3D"">potswa@gmail.com</a>&gt; wrote:</div><br class=3D"Apple-inter=
change-newline"><div class=3D""><div class=3D"" style=3D"word-wrap: break-w=
ord; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><div=
 class=3D""><blockquote type=3D"cite" class=3D"" style=3D"font-family: Helv=
etica; font-size: 12px; font-style: normal; font-variant: normal; font-weig=
ht: normal; letter-spacing: normal; line-height: normal; orphans: auto; tex=
t-align: start; text-indent: 0px; text-transform: none; white-space: normal=
; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><div cl=
ass=3D""><div dir=3D"ltr" class=3D""><div class=3D"">Section 1.1: In bullet=
 1, IIUC you're talking about unsafe access to shared global state (e.g. st=
d::cout). const qualification can't help with that, but nor should it be ex=
pected to.<span class=3D"Apple-converted-space">&nbsp;</span></div></div></=
div></blockquote><div style=3D"font-family: Helvetica; font-size: 12px; fon=
t-style: normal; font-variant: normal; font-weight: normal; letter-spacing:=
 normal; line-height: normal; orphans: auto; text-align: start; text-indent=
: 0px; text-transform: none; white-space: normal; widows: auto; word-spacin=
g: 0px; -webkit-text-stroke-width: 0px;" class=3D""><br class=3D""></div><d=
iv style=3D"font-family: Helvetica; font-size: 12px; font-style: normal; fo=
nt-variant: normal; font-weight: normal; letter-spacing: normal; line-heigh=
t: normal; orphans: auto; text-align: start; text-indent: 0px; text-transfo=
rm: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-tex=
t-stroke-width: 0px;" class=3D"">That=E2=80=99s the fundamental problem wit=
h [res.on.data.races]/2-3: it presumes reasonable expectations. But why tak=
e an =E2=80=9Cunexpected=E2=80=9D interpretation of =C2=B63 without applyin=
g the same to =C2=B62?</div></div></div></div></blockquote></div><br class=
=3D""><div class=3D"">(To be sure, the note in =C2=B64 specifically mention=
s shared global state, so such interpretations don=E2=80=99t seem so unexpe=
cted.)</div><div class=3D""><br class=3D""></div></body></html>

<p></p>

-- <br />
<br />
--- <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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--Apple-Mail=_243B46E4-53E7-4BF9-A654-35ADE9A1EC31--

.