Topic: Class helpers (was: Small contribution to
Author: Nevin Liber <nevin@eviloverlord.com>
Date: Thu, 19 Nov 2015 16:23:43 -0600
Raw View
--089e0141a1628d14e20524ec381a
Content-Type: text/plain; charset=UTF-8
On 19 November 2015 at 16:08, John Yates <john@yates-sheets.org> wrote:
> A tension I have encountered repeatedly (and resolve differently on
> different occasions) is the requirement to make a function a class member
> in-order to confer upon it method invocation syntax.
>
Is there anything in here not covered by the Unified Call Syntax (n4474
<http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/n4474.pdf> and
p0131r0
<http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/p0131r0.pdf>)
proposal?
Not that you'll necessarily agree with the conclusion, but after debating
this at multiple meetings, I believe the direction reached by EWG in Kona
is that f(x, ...) can implicitly call x.f(...), but not the other way
around.
--
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
--089e0141a1628d14e20524ec381a
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On 19 November 2015 at 16:08, John Yates <span dir=3D"ltr"=
><<a href=3D"mailto:john@yates-sheets.org" target=3D"_blank">john@yates-=
sheets.org</a>></span> wrote:<br><div class=3D"gmail_extra"><div class=
=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8=
ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div>A ten=
sion I have encountered repeatedly (and resolve differently on different oc=
casions) is the requirement to make a function a class member in-order to c=
onfer upon it method invocation syntax.</div></div></blockquote><div><br></=
div><div>Is there anything in here not covered by the Unified Call Syntax (=
<a href=3D"http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/n4474.pd=
f" target=3D"_blank">n4474</a>=C2=A0and=C2=A0<a href=3D"http://www.open-std=
..org/jtc1/sc22/wg21/docs/papers/2015/p0131r0.pdf">p0131r0</a>) proposal?</d=
iv><div><br></div><div>Not that you'll necessarily agree with the concl=
usion, but after debating this at multiple meetings, I believe the directio=
n reached by EWG in Kona is that f(x, ...) can implicitly call x.f(...), bu=
t not the other way around.</div></div>-- <br><div><div dir=3D"ltr"><div><d=
iv dir=3D"ltr"><div>=C2=A0Nevin ":-)" Liber=C2=A0 <mailto:<a h=
ref=3D"mailto:nevin@eviloverlord.com" target=3D"_blank">nevin@eviloverlord.=
com</a>> =C2=A0<a href=3D"tel:%2B1-847-691-1404" value=3D"+18476911404" =
target=3D"_blank">+1-847-691-1404</a></div></div></div></div></div>
</div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
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 />
--089e0141a1628d14e20524ec381a--
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Thu, 19 Nov 2015 15:59:14 -0800 (PST)
Raw View
------=_Part_1155_656597660.1447977554334
Content-Type: multipart/alternative;
boundary="----=_Part_1156_563511749.1447977554334"
------=_Part_1156_563511749.1447977554334
Content-Type: text/plain; charset=UTF-8
On Thursday, November 19, 2015 at 5:24:25 PM UTC-5, Nevin ":-)" Liber wrote:
>
> On 19 November 2015 at 16:08, John Yates <jo...@yates-sheets.org
> <javascript:>> wrote:
>
>> A tension I have encountered repeatedly (and resolve differently on
>> different occasions) is the requirement to make a function a class member
>> in-order to confer upon it method invocation syntax.
>>
>
> Is there anything in here not covered by the Unified Call Syntax (n4474
> <http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/n4474.pdf> and
> p0131r0
> <http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/p0131r0.pdf>)
> proposal?
>
> Not that you'll necessarily agree with the conclusion, but after debating
> this at multiple meetings, I believe the direction reached by EWG in Kona
> is that f(x, ...) can implicitly call x.f(...), but not the other way
> around.
>
It should also be noted that the committee struck down exactly what he is
asking for, in P0079. That is, the ability to declare that a non-member
should be callable as a member of a class.
--
---
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/.
------=_Part_1156_563511749.1447977554334
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<br><br>On Thursday, November 19, 2015 at 5:24:25 PM UTC-5, Nevin ":-)=
" Liber wrote:<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">On 19 November 2015 at 16:08, John Yates <span dir=3D"ltr"><<a hre=
f=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"-APtnsQMBQAJ" =
rel=3D"nofollow" onmousedown=3D"this.href=3D'javascript:';return tr=
ue;" onclick=3D"this.href=3D'javascript:';return true;">jo...@yates=
-sheets.org</a>></span> wrote:<br><div><div class=3D"gmail_quote"><block=
quote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc=
solid;padding-left:1ex"><div dir=3D"ltr"><div>A tension I have encountered=
repeatedly (and resolve differently on different occasions) is the require=
ment to make a function a class member in-order to confer upon it method in=
vocation syntax.</div></div></blockquote><div><br></div><div>Is there anyth=
ing in here not covered by the Unified Call Syntax (<a href=3D"http://www.o=
pen-std.org/jtc1/sc22/wg21/docs/papers/2015/n4474.pdf" target=3D"_blank" re=
l=3D"nofollow" onmousedown=3D"this.href=3D'http://www.google.com/url?q\=
75http%3A%2F%2Fwww.open-std.org%2Fjtc1%2Fsc22%2Fwg21%2Fdocs%2Fpapers%2F2015=
%2Fn4474.pdf\46sa\75D\46sntz\0751\46usg\75AFQjCNHFigxJItStW1U7PDXJ6n-EiK3h_=
A';return true;" onclick=3D"this.href=3D'http://www.google.com/url?=
q\75http%3A%2F%2Fwww.open-std.org%2Fjtc1%2Fsc22%2Fwg21%2Fdocs%2Fpapers%2F20=
15%2Fn4474.pdf\46sa\75D\46sntz\0751\46usg\75AFQjCNHFigxJItStW1U7PDXJ6n-EiK3=
h_A';return true;">n4474</a>=C2=A0and=C2=A0<a href=3D"http://www.open-s=
td.org/jtc1/sc22/wg21/docs/papers/2015/p0131r0.pdf" target=3D"_blank" rel=
=3D"nofollow" onmousedown=3D"this.href=3D'http://www.google.com/url?q\7=
5http%3A%2F%2Fwww.open-std.org%2Fjtc1%2Fsc22%2Fwg21%2Fdocs%2Fpapers%2F2015%=
2Fp0131r0.pdf\46sa\75D\46sntz\0751\46usg\75AFQjCNFgArzPPqWPRJyeFIsqQqR6veJ1=
Ew';return true;" onclick=3D"this.href=3D'http://www.google.com/url=
?q\75http%3A%2F%2Fwww.open-std.org%2Fjtc1%2Fsc22%2Fwg21%2Fdocs%2Fpapers%2F2=
015%2Fp0131r0.pdf\46sa\75D\46sntz\0751\46usg\75AFQjCNFgArzPPqWPRJyeFIsqQqR6=
veJ1Ew';return true;">p0131r0</a>) proposal?</div></div></div></div></b=
lockquote><div></div><blockquote class=3D"gmail_quote" style=3D"margin: 0;m=
argin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=
=3D"ltr"><div><div class=3D"gmail_quote"><div><br></div><div>Not that you&#=
39;ll necessarily agree with the conclusion, but after debating this at mul=
tiple meetings, I believe the direction reached by EWG in Kona is that f(x,=
...) can implicitly call x.f(...), but not the other way around.</div></di=
v></div></div></blockquote><div><br>It should also be noted that the commit=
tee struck down exactly what he is asking for, in P0079. That is, the abili=
ty to declare that a non-member should be callable as a member of a class.<=
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" 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 />
------=_Part_1156_563511749.1447977554334--
------=_Part_1155_656597660.1447977554334--
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Thu, 19 Nov 2015 16:18:01 -0800 (PST)
Raw View
------=_Part_1401_932264062.1447978682059
Content-Type: multipart/alternative;
boundary="----=_Part_1402_1224316559.1447978682060"
------=_Part_1402_1224316559.1447978682060
Content-Type: text/plain; charset=UTF-8
On Thursday, November 19, 2015 at 5:08:31 PM UTC-5, John Yates wrote:
>
> I am posting this as a new thread because I do not want to undermine the
> ongoing discussion of what I will term the "namespace class" proposal.
>
> Assuming that proposal is successful I see opportunity to address another
> C++ rough edge. As in the former proposal this adds no actual new
> functionality to C++ but it would make it more pleasant to use.
>
No, inserting functions into a class from outside of the class's definition
is very much adding new functionality. It's either directly inserting
methods into a class or its changing what `x.f(...)` could call. Either
way, it is very much doing something that couldn't be done before.
Ideally I want my users to use method invocation syntax to call operations
> in this second set. And indeed I can achieve that by including those
> operations in the class definition. Often though that seems a high price
> to pay merely to achieve syntactic uniformity.
>
Why do you consider making a member function to be "a high price"?
> Already today a classic namespace need not be defined all at once.
> Disparate sites can open the same namespace in order to add entries. I
> would like to suggest that "namespace class" have a similar behavior:
>
Until your little addendum, there was no such thing as a "namespace class".
A "namespace class" declaration, as defined in the other thread, is not
creating a construct. It is not a namespace that is a class or anything of
the kind. It is merely a way to avoid adding repetitive syntax when
defining members of a class. The `namespace` keyword is simply being used
to tell the compiler that this is not a class definition.
What you want transforms this from being merely syntactic sugar into
actually *meaning* something. Your idea makes a "namespace class" an actual
language construct.
>
> - If a "namespace class" function definition has a signature that
> matches a method within the corresponding class still missing a definition
> then it "completes" that method.
> - Otherwise such a"namespace class" function becomes a member of the
> namespace class (but not the class). It must be called using method
> invocation syntax. Its implementation can use unqualified naming to refer
> to public members of the clas. OTOH it is granted no special access (it is
> restricted to exploiting the public interface).
>
> OK, so how does that work? Do they have an implicit `this` pointer? Are
those functions considered namespace-scoped functions or member functions?
If they're member functions, can you get member pointers to them? If not...
what does this mean? How do you name these functions? Would you say
`X::FuncName`?
Are you allowed to inject constructors into classes? What about special
member functions like assignment operators? What about those overloaded
operators that have to be declared as members of types; can those too be
injected?
Can you declare `using namespace X`, where X is the "namespace class" and
have that actually do something? What would it mean? Can you declare an
namespace class `inline`?
Maybe you should think the idea through a bit more.
>
> - No virtual nor static functions.
> - No data (neither static nor instance).
>
> Why not? I mean, if you can insert functions into a class, why not be able
to insert at least static data members?
--
---
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/.
------=_Part_1402_1224316559.1447978682060
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Thursday, November 19, 2015 at 5:08:31 PM UTC-5, John Y=
ates 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">I =
am posting this as a new thread because I do not want to undermine the ongo=
ing discussion of what I will term the "namespace class" proposal=
..<div><br></div><div>Assuming that proposal is successful I see opportunity=
to address another C++ rough edge.=C2=A0 As in the former proposal this ad=
ds no actual new functionality to C++ but it would make it more pleasant to=
use.</div></div></blockquote><div><br>No, inserting functions into a class=
from outside of the class's definition is very much adding new functio=
nality. It's either directly inserting methods into a class or its chan=
ging what `x.f(...)` could call. Either way, it is very much doing somethin=
g that couldn't be done before.<br><br></div><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>Ideally I want my users to use met=
hod invocation syntax to call operations in this second set. And indeed I c=
an achieve that by including those operations in the class definition.=C2=
=A0 Often though that seems a high price to pay merely to achieve syntactic=
uniformity.</div></div></blockquote><div><br>Why do you consider making a =
member function to be "a high price"?<br>=C2=A0</div><blockquote =
class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1p=
x #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div></div><div>Already t=
oday a classic namespace need not be defined all at once.=C2=A0 Disparate s=
ites can open the same namespace in order to add entries.=C2=A0 I would lik=
e to suggest that "namespace class" have a similar behavior:<br><=
/div></div></blockquote><div><br>Until your little addendum, there was no s=
uch thing as a "namespace class". A "namespace class" d=
eclaration, as defined in the other thread, is not creating a construct. It=
is not a namespace that is a class or anything of the kind. It is merely a=
way to avoid adding repetitive syntax when defining members of a class. Th=
e `namespace` keyword is simply being used to tell the compiler that this i=
s not a class definition.<br><br>What you want transforms this from being m=
erely syntactic sugar into actually <i>meaning</i> something. Your idea mak=
es a "namespace class" an actual language construct.<br></div><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></div><div>=
<ul><li>If a "namespace class" function definition has a signatur=
e that matches a method within the corresponding class still missing a defi=
nition then it "completes" that method.</li><li>Otherwise such a&=
quot;namespace class" function becomes a member of the namespace class=
(but not the class).=C2=A0 It must be called using method invocation synta=
x.=C2=A0 Its implementation can use unqualified naming to refer to public m=
embers of the clas.=C2=A0 OTOH it is granted no special access (it is restr=
icted to exploiting the public interface).</li></ul></div></div></blockquot=
e><div>OK, so how does that work? Do they have an implicit `this` pointer? =
Are those functions considered namespace-scoped functions or member functio=
ns? If they're member functions, can you get member pointers to them? I=
f not... what does this mean? How do you name these functions? Would you sa=
y `X::FuncName`?<br><br>Are you allowed to inject constructors into classes=
? What about special member functions like assignment operators? What about=
those overloaded operators that have to be declared as members of types; c=
an those too be injected?<br><br>Can you declare `using namespace X`, where=
X is the "namespace class" and have that actually do something? =
What would it mean? Can you declare an namespace class `inline`?<br><br>May=
be you should think the idea through a bit more.<br></div><blockquote class=
=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><ul><li>No virtual nor st=
atic functions.</li><li>No data (neither static nor instance).</li></ul></d=
iv></div></blockquote><div>Why not? I mean, if you can insert functions int=
o a class, why not be able to insert at least static data members?</div></d=
iv>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
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 />
------=_Part_1402_1224316559.1447978682060--
------=_Part_1401_932264062.1447978682059--
.
Author: John Yates <john@yates-sheets.org>
Date: Thu, 19 Nov 2015 22:49:55 -0500
Raw View
--047d7bd6bc38cadcd30524f0c4d6
Content-Type: text/plain; charset=UTF-8
On Thu, Nov 19, 2015 at 5:23 PM, Nevin Liber <nevin@eviloverlord.com> wrote:
> Is there anything in here not covered by the Unified Call Syntax (n4474
> <http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/n4474.pdf> and
> p0131r0
> <http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/p0131r0.pdf>)
> proposal?
>
After reading your references more attentively and especially follwoing
Nicol's comments I have recast my ideas. More to follow.
/john
--
---
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/.
--047d7bd6bc38cadcd30524f0c4d6
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, Nov 19, 2015 at 5:23 PM, Nevin Liber <span dir=3D"ltr"><<a href=3D"m=
ailto:nevin@eviloverlord.com" target=3D"_blank">nevin@eviloverlord.com</a>&=
gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0px =
0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);bord=
er-left-style:solid;padding-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_=
extra"><div class=3D"gmail_quote"><span class=3D""><div>Is there anything i=
n here not covered by the Unified Call Syntax (<a href=3D"http://www.open-s=
td.org/jtc1/sc22/wg21/docs/papers/2015/n4474.pdf" target=3D"_blank">n4474</=
a>=C2=A0and=C2=A0<a href=3D"http://www.open-std.org/jtc1/sc22/wg21/docs/pap=
ers/2015/p0131r0.pdf" target=3D"_blank">p0131r0</a>) proposal?<br></div></s=
pan></div></div></div></blockquote><div><br></div><div>After reading your r=
eferences more attentively and especially follwoing Nicol's comments I =
have recast my ideas.=C2=A0 More to follow.</div><div><br></div><div>/john<=
/div><div><br></div></div></div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
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 />
--047d7bd6bc38cadcd30524f0c4d6--
.