Topic: Proposal: Explicit Object Parameter
Author: Andrew Tomazos <andrewtomazos@gmail.com>
Date: Wed, 30 Oct 2013 01:51:26 -0700 (PDT)
Raw View
------=_Part_1023_23590538.1383123086546
Content-Type: text/plain; charset=ISO-8859-1
One of the useful features of member functions is that name lookup occurs
within their class scope and for non-static member functions they have an
implicit object parameter.
The primary expression this gives a pointer to this object parameter, but
more importantly name lookup, id-expressions and function call expressions
will use the class scope of the implicit object parameter and implicitly
use this for non-static data members and non-static member function calls.
It would be great if we could nominate a parameter of a freestanding
function to act as an implicit object parameter.
This would give us the ability to define a new freestanding function with a
class type parameter separately from the class specifier as we can now, but
still use the convenient syntax enjoyed inside member function definitions.
For this I propose using the keyword this as the parameter declarator-id to
nominate which parameter is the "explicit object parameter".
Also perhaps an alias for functions with such an explicit object parameter
could be added to the class scope, so that they could be called as if they
were member functions after their declaration within a translation unit.
Let's take an example:
struct C
{
void f();
};
void g(C this)
{
f();
}
int main()
{
C c;
g(c);
}
Another example:
M.h
struct M
{
int i;
void add42();
};
M.cpp
static void add(M this, int x)
{
i += x;
}
void M::add42()
{
add(42);
}
And another:
struct AnimalVisitor
{
static void visit(Dog this) { bark(); }
static void visit(Cat this) { meow(); }
static void visit(Pig this) { oink(); }
};
Explicit object parameters are not allowed on non-static member functions
(they already have an implicit object parameter).
When an explicit object parameter declarator-id this is encountered the
scope changes to the class scope of the parameter type, in much the same
way as scope changes after a qualified declarator-id.
Details of the interaction with member access control, friends and a few
other things still need to be worked out, and there would need to be an
implementation before a formal proposal - but what do you think? Is this
worth pursuing / of interest?
--
---
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_1023_23590538.1383123086546
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br>One of the useful features of member functions is that=
name lookup occurs within their class scope and for non-static member func=
tions they have an implicit object parameter.<br><br>The primary expression=
<span style=3D"font-family: courier new,monospace;">this</span> gives a po=
inter to this object parameter, but more importantly name lookup, id-expres=
sions and function call expressions will use the class scope of the implici=
t object parameter and implicitly use <span style=3D"font-family: courier n=
ew,monospace;">this</span> for non-static data members and non-static membe=
r function calls.<br><br>It would be great if we could nominate a parameter=
of a freestanding function to act as an implicit object parameter.<br><br>=
This would give us the ability to define a new freestanding function with a=
class type parameter separately from the class specifier as we can now, bu=
t still use the convenient syntax enjoyed inside member function definition=
s.<br><br>For this I propose using the keyword <span style=3D"font-family: =
courier new,monospace;">this</span> as the parameter declarator-id to nomin=
ate which parameter is the "explicit object parameter".<br><br>Also perhaps=
an alias for functions with such an explicit object parameter could be add=
ed to the class scope, so that they could be called as if they were member =
functions after their declaration within a translation unit.<br><br>Let's t=
ake an example:<br><br> struct C<br> {<=
br> void f();<br> &nbs=
p; };<br><br> void g(C this)<br> {<br>&=
nbsp; f();<br> }<br><=
br> int main()<br> {<br> &nb=
sp; C c;<br><br>  =
; g(c);<br> }<br><br>Another example:<br><br>M.h<br=
><br> struct M<br> {<br> &nb=
sp; int i;<br><br> &nb=
sp; void add42();<br> };<br><br>M.cpp<br><br> =
static void add(M this, int x)<br> {<br>&nbs=
p; i +=3D x;<br> }<br=
><br> void M::add42()<br> {<br> &n=
bsp; add(42);<br> }<br><br>=
And another:<br><br> struct AnimalVisitor<br> =
{<br> static void visit(Do=
g this) { bark(); }<br> static vo=
id visit(Cat this) { meow(); }<br>  =
; static void visit(Pig this) { oink(); }<br> };<br><br>E=
xplicit object parameters are not allowed on non-static member functions (t=
hey already have an implicit object parameter).<br><br>When an explicit obj=
ect parameter declarator-id this is encountered the scope changes to the cl=
ass scope of the parameter type, in much the same way as scope changes afte=
r a qualified declarator-id.<br><br>Details of the interaction with member =
access control, friends and a few other things still need to be worked out,=
and there would need to be an implementation before a formal proposal - bu=
t what do you think? Is this worth pursuing / of interest?<br><br></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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<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_1023_23590538.1383123086546--
.
Author: Xeo <hivemaster@hotmail.de>
Date: Wed, 30 Oct 2013 02:40:11 -0700 (PDT)
Raw View
------=_Part_996_22847751.1383126011064
Content-Type: text/plain; charset=ISO-8859-1
Why don't you just call it "Extension Methods"? :) Because that's exactly
what this seems to be.
On Wednesday, October 30, 2013 9:51:26 AM UTC+1, Andrew Tomazos wrote:
>
>
> One of the useful features of member functions is that name lookup occurs
> within their class scope and for non-static member functions they have an
> implicit object parameter.
>
> The primary expression this gives a pointer to this object parameter, but
> more importantly name lookup, id-expressions and function call expressions
> will use the class scope of the implicit object parameter and implicitly
> use this for non-static data members and non-static member function calls.
>
> It would be great if we could nominate a parameter of a freestanding
> function to act as an implicit object parameter.
>
> This would give us the ability to define a new freestanding function with
> a class type parameter separately from the class specifier as we can now,
> but still use the convenient syntax enjoyed inside member function
> definitions.
>
> For this I propose using the keyword this as the parameter declarator-id
> to nominate which parameter is the "explicit object parameter".
>
> Also perhaps an alias for functions with such an explicit object parameter
> could be added to the class scope, so that they could be called as if they
> were member functions after their declaration within a translation unit.
>
> Let's take an example:
>
> struct C
> {
> void f();
> };
>
> void g(C this)
> {
> f();
> }
>
> int main()
> {
> C c;
>
> g(c);
> }
>
> Another example:
>
> M.h
>
> struct M
> {
> int i;
>
> void add42();
> };
>
> M.cpp
>
> static void add(M this, int x)
> {
> i += x;
> }
>
> void M::add42()
> {
> add(42);
> }
>
> And another:
>
> struct AnimalVisitor
> {
> static void visit(Dog this) { bark(); }
> static void visit(Cat this) { meow(); }
> static void visit(Pig this) { oink(); }
> };
>
> Explicit object parameters are not allowed on non-static member functions
> (they already have an implicit object parameter).
>
> When an explicit object parameter declarator-id this is encountered the
> scope changes to the class scope of the parameter type, in much the same
> way as scope changes after a qualified declarator-id.
>
> Details of the interaction with member access control, friends and a few
> other things still need to be worked out, and there would need to be an
> implementation before a formal proposal - but what do you think? Is this
> worth pursuing / of interest?
>
>
--
---
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_996_22847751.1383126011064
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Why don't you just call it "Extension Methods"? :) Because=
that's exactly what this seems to be.<br><br>On Wednesday, October 30, 201=
3 9:51:26 AM UTC+1, Andrew Tomazos wrote:<blockquote class=3D"gmail_quote" =
style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-l=
eft: 1ex;"><div dir=3D"ltr"><br>One of the useful features of member functi=
ons is that name lookup occurs within their class scope and for non-static =
member functions they have an implicit object parameter.<br><br>The primary=
expression <span style=3D"font-family:courier new,monospace">this</span> g=
ives a pointer to this object parameter, but more importantly name lookup, =
id-expressions and function call expressions will use the class scope of th=
e implicit object parameter and implicitly use <span style=3D"font-family:c=
ourier new,monospace">this</span> for non-static data members and non-stati=
c member function calls.<br><br>It would be great if we could nominate a pa=
rameter of a freestanding function to act as an implicit object parameter.<=
br><br>This would give us the ability to define a new freestanding function=
with a class type parameter separately from the class specifier as we can =
now, but still use the convenient syntax enjoyed inside member function def=
initions.<br><br>For this I propose using the keyword <span style=3D"font-f=
amily:courier new,monospace">this</span> as the parameter declarator-id to =
nominate which parameter is the "explicit object parameter".<br><br>Also pe=
rhaps an alias for functions with such an explicit object parameter could b=
e added to the class scope, so that they could be called as if they were me=
mber functions after their declaration within a translation unit.<br><br>Le=
t's take an example:<br><br> struct C<br> &nbs=
p; {<br> void f();<br>  =
; };<br><br> void g(C this)<br> {=
<br> f();<br> }=
<br><br> int main()<br> {<br> &nbs=
p; C c;<br><br> =
g(c);<br> }<br><br>Another example:<br><br>M=
..h<br><br> struct M<br> {<br> &nbs=
p; int i;<br><br> &nbs=
p; void add42();<br> };<br><br>M.cpp<br><br>&=
nbsp; static void add(M this, int x)<br> {<br=
> i +=3D x;<br> =
}<br><br> void M::add42()<br> {<br>&nb=
sp; add(42);<br> }<br=
><br>And another:<br><br> struct AnimalVisitor<br> &=
nbsp; {<br> static void vis=
it(Dog this) { bark(); }<br> stat=
ic void visit(Cat this) { meow(); }<br> =
static void visit(Pig this) { oink(); }<br> };<br>=
<br>Explicit object parameters are not allowed on non-static member functio=
ns (they already have an implicit object parameter).<br><br>When an explici=
t object parameter declarator-id this is encountered the scope changes to t=
he class scope of the parameter type, in much the same way as scope changes=
after a qualified declarator-id.<br><br>Details of the interaction with me=
mber access control, friends and a few other things still need to be worked=
out, and there would need to be an implementation before a formal proposal=
- but what do you think? Is this worth pursuing / of interest?<br><b=
r></div></blockquote></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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<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_996_22847751.1383126011064--
.
Author: Bengt Gustafsson <bengt.gustafsson@beamways.com>
Date: Sun, 3 Nov 2013 04:52:41 -0800 (PST)
Raw View
------=_Part_3090_6317000.1383483161182
Content-Type: text/plain; charset=ISO-8859-1
I like this idea, although there may be possible problems with reusing the
this codeword. People on this list are usually good at spotting such
problems, but so far there have been no postings on this.
I initially thought that this feature would solve the problem also
discussed recently of how to avoid having to show declarations of private
(non virtual) methods in the class head. This would however require that
accessing private members were allowed for such "artifical" this variables
(explicitly and implicitly). This would however offer a possibility to
"break into" classes which may be undesired.
@Xeo: Programming is full of paradigms and terminologies. I think we should
try to not assume that people are aware of certain terms for certain things
outside the C++ area, especially if not mentioning where the term comes
from. In this case I don't see any point in your post at all except showing
off your superior knowledge, and in many other cases discussions get
severely muddled by people thinking that what they know from other parts of
the programming world is obvious by just stating a term or acronym, often
without mentioning the source such as "as in Python" or similar.
Den onsdagen den 30:e oktober 2013 kl. 10:40:11 UTC+1 skrev Xeo:
>
> Why don't you just call it "Extension Methods"? :) Because that's exactly
> what this seems to be.
>
> On Wednesday, October 30, 2013 9:51:26 AM UTC+1, Andrew Tomazos wrote:
>>
>>
>> One of the useful features of member functions is that name lookup occurs
>> within their class scope and for non-static member functions they have an
>> implicit object parameter.
>>
>> The primary expression this gives a pointer to this object parameter,
>> but more importantly name lookup, id-expressions and function call
>> expressions will use the class scope of the implicit object parameter and
>> implicitly use this for non-static data members and non-static member
>> function calls.
>>
>> It would be great if we could nominate a parameter of a freestanding
>> function to act as an implicit object parameter.
>>
>> This would give us the ability to define a new freestanding function with
>> a class type parameter separately from the class specifier as we can now,
>> but still use the convenient syntax enjoyed inside member function
>> definitions.
>>
>> For this I propose using the keyword this as the parameter declarator-id
>> to nominate which parameter is the "explicit object parameter".
>>
>> Also perhaps an alias for functions with such an explicit object
>> parameter could be added to the class scope, so that they could be called
>> as if they were member functions after their declaration within a
>> translation unit.
>>
>> Let's take an example:
>>
>> struct C
>> {
>> void f();
>> };
>>
>> void g(C this)
>> {
>> f();
>> }
>>
>> int main()
>> {
>> C c;
>>
>> g(c);
>> }
>>
>> Another example:
>>
>> M.h
>>
>> struct M
>> {
>> int i;
>>
>> void add42();
>> };
>>
>> M.cpp
>>
>> static void add(M this, int x)
>> {
>> i += x;
>> }
>>
>> void M::add42()
>> {
>> add(42);
>> }
>>
>> And another:
>>
>> struct AnimalVisitor
>> {
>> static void visit(Dog this) { bark(); }
>> static void visit(Cat this) { meow(); }
>> static void visit(Pig this) { oink(); }
>> };
>>
>> Explicit object parameters are not allowed on non-static member functions
>> (they already have an implicit object parameter).
>>
>> When an explicit object parameter declarator-id this is encountered the
>> scope changes to the class scope of the parameter type, in much the same
>> way as scope changes after a qualified declarator-id.
>>
>> Details of the interaction with member access control, friends and a few
>> other things still need to be worked out, and there would need to be an
>> implementation before a formal proposal - but what do you think? Is this
>> worth pursuing / of interest?
>>
>>
--
---
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_3090_6317000.1383483161182
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div>I like this idea, although there may be possible prob=
lems with reusing the this codeword. People on this list are usually good a=
t spotting such problems, but so far there have been no postings on this.</=
div><div><br></div><div>I initially thought that this feature would solve t=
he problem also discussed recently of how to avoid having to show declarati=
ons of private (non virtual) methods in the class head. This would however =
require that accessing private members were allowed for such "artifical" th=
is variables (explicitly and implicitly). This would however offer a possib=
ility to "break into" classes which may be undesired. </div><div><br><=
/div>@Xeo: Programming is full of paradigms and terminologies. I think we s=
hould try to not assume that people are aware of certain terms for certain =
things outside the C++ area, especially if not mentioning where the term co=
mes from. In this case I don't see any point in your post at all except sho=
wing off your superior knowledge, and in many other cases discussions get s=
everely muddled by people thinking that what they know from other parts of =
the programming world is obvious by just stating a term or acronym, often w=
ithout mentioning the source such as "as in Python" or similar.<div><br></d=
iv><div><br><br>Den onsdagen den 30:e oktober 2013 kl. 10:40:11 UTC+1 skrev=
Xeo:<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">Why don'=
t you just call it "Extension Methods"? :) Because that's exactly what this=
seems to be.<br><br>On Wednesday, October 30, 2013 9:51:26 AM UTC+1, Andre=
w Tomazos 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"><b=
r>One of the useful features of member functions is that name lookup occurs=
within their class scope and for non-static member functions they have an =
implicit object parameter.<br><br>The primary expression <span style=3D"fon=
t-family:courier new,monospace">this</span> gives a pointer to this object =
parameter, but more importantly name lookup, id-expressions and function ca=
ll expressions will use the class scope of the implicit object parameter an=
d implicitly use <span style=3D"font-family:courier new,monospace">this</sp=
an> for non-static data members and non-static member function calls.<br><b=
r>It would be great if we could nominate a parameter of a freestanding func=
tion to act as an implicit object parameter.<br><br>This would give us the =
ability to define a new freestanding function with a class type parameter s=
eparately from the class specifier as we can now, but still use the conveni=
ent syntax enjoyed inside member function definitions.<br><br>For this I pr=
opose using the keyword <span style=3D"font-family:courier new,monospace">t=
his</span> as the parameter declarator-id to nominate which parameter is th=
e "explicit object parameter".<br><br>Also perhaps an alias for functions w=
ith such an explicit object parameter could be added to the class scope, so=
that they could be called as if they were member functions after their dec=
laration within a translation unit.<br><br>Let's take an example:<br><br>&n=
bsp; struct C<br> {<br> &nbs=
p; void f();<br> };<br><br> =
void g(C this)<br> {<br> &n=
bsp; f();<br> }<br><br> int=
main()<br> {<br> &nbs=
p; C c;<br><br> g(c);<br> &n=
bsp; }<br><br>Another example:<br><br>M.h<br><br> s=
truct M<br> {<br> &nbs=
p; int i;<br><br> void add42();<b=
r> };<br><br>M.cpp<br><br> static void =
add(M this, int x)<br> {<br>  =
; i +=3D x;<br> }<br><br> v=
oid M::add42()<br> {<br> &nb=
sp; add(42);<br> }<br><br>And another:<br><br> =
; struct AnimalVisitor<br> {<br> &=
nbsp; static void visit(Dog this) { bark(); }<br>&n=
bsp; static void visit(Cat this) { meow=
(); }<br> static void visit(Pig t=
his) { oink(); }<br> };<br><br>Explicit object parameters=
are not allowed on non-static member functions (they already have an impli=
cit object parameter).<br><br>When an explicit object parameter declarator-=
id this is encountered the scope changes to the class scope of the paramete=
r type, in much the same way as scope changes after a qualified declarator-=
id.<br><br>Details of the interaction with member access control, friends a=
nd a few other things still need to be worked out, and there would need to =
be an implementation before a formal proposal - but what do you think? =
; Is this worth pursuing / of interest?<br><br></div></blockquote></div></b=
lockquote></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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<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_3090_6317000.1383483161182--
.
Author: Andrew Tomazos <andrewtomazos@gmail.com>
Date: Sun, 3 Nov 2013 05:42:05 -0800 (PST)
Raw View
------=_Part_2079_5029992.1383486125114
Content-Type: text/plain; charset=ISO-8859-1
On Sunday, November 3, 2013 1:52:41 PM UTC+1, Bengt Gustafsson wrote:
>
> I like this idea, although there may be possible problems with reusing the
> this codeword. People on this list are usually good at spotting such
> problems, but so far there have been no postings on this.
>
> I initially thought that this feature would solve the problem also
> discussed recently of how to avoid having to show declarations of private
> (non virtual) methods in the class head. This would however require that
> accessing private members were allowed for such "artifical" this variables
> (explicitly and implicitly). This would however offer a possibility to
> "break into" classes which may be undesired.
>
As mentioned, I haven't studied the member access control issues as closely
as I would like yet.
One approach would be to newly include access-specifier as a possible
decl-specifier, and this would provide that level of access to the
parameter.
So for example:
M.h
struct M
{
void add42();
private:
int i;
};
M.cpp
static void add(private M this, int x)
{
i += x;
}
void M::add42()
{
add(42);
}
With no access-specifier, the default access level is as it is now, public.
Whether such an access-specifier override would only be allowed on these
explicit object parameters, or whether such an access override would be
allowed orthogonally to any declaration of class type...
class C { private: int x; }
void f(private C& c) { c.x++; } // ok
....I'm not sure.
The interaction with friend classes and friend functions also needs to be
studied.
Also I see the explicit object parameter feature, as well as the
access-specifier override idea, playing well with virtual parameters and
multi-methods: http://www.stroustrup.com/multimethods.pdf. Having a
double-dispatch function (whether static or dynamic) with private access to
both its object parameters is clearly desirable and sensible in a number of
use cases.
I've been playing with the idea of packaging these features all up together
in a new major proposed feature called Free Methods, and making an
implementation. It's not clear to me yet if there is sufficient interest.
--
---
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_2079_5029992.1383486125114
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Sunday, November 3, 2013 1:52:41 PM UTC+1, Bengt Gustaf=
sson 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"><d=
iv>I like this idea, although there may be possible problems with reusing t=
he this codeword. People on this list are usually good at spotting such pro=
blems, but so far there have been no postings on this.</div><div><br></div>=
<div>I initially thought that this feature would solve the problem also dis=
cussed recently of how to avoid having to show declarations of private (non=
virtual) methods in the class head. This would however require that access=
ing private members were allowed for such "artifical" this variables (expli=
citly and implicitly). This would however offer a possibility to "break int=
o" classes which may be undesired. <br></div></div></blockquote><div><br>As=
mentioned, I haven't studied the member access control issues as closely a=
s I would like yet.<br><br>One approach would be to newly include access-sp=
ecifier as a possible decl-specifier, and this would provide that level of =
access to the parameter.<br><br>So for example:<br><br>M.h<br><br> &nb=
sp; struct M<br> {<br><br> &=
nbsp; void add42();<br><br> private:<br> =
; int i;<br><br> };<b=
r><br>M.cpp<br><br> static void add(private M this, int x=
)<br> {<br> i +=
=3D x;<br> }<br><br> void M::add42()<br=
> {<br> add(42)=
;<br> }<br><br>With no access-specifier, the default acce=
ss level is as it is now, public.<br><br>Whether such an access-specifier o=
verride would only be allowed on these explicit object parameters, or wheth=
er such an access override would be allowed orthogonally to any declaration=
of class type...<br><br> class C { private: int x; }<br>=
void f(private C& c) { c.x++; } // ok <br><br>...I'm=
not sure.<br><br>The interaction with friend classes and friend functions =
also needs to be studied.<br><br>Also I see the explicit object parameter f=
eature, as well as the access-specifier override idea, playing well with vi=
rtual parameters and multi-methods: http://www.stroustrup.com/multimethods.=
pdf. Having a double-dispatch function (whether static or dynamic) wi=
th private access to both its object parameters is clearly desirable and se=
nsible in a number of use cases.<br><br>I've been playing with the idea of =
packaging these features all up together in a new major proposed feature ca=
lled Free Methods, and making an implementation. It's not clear to me=
yet if there is sufficient interest.<br><br></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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<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_2079_5029992.1383486125114--
.
Author: walter1234 <walter2bz@gmail.com>
Date: Wed, 11 Jun 2014 03:46:52 -0700 (PDT)
Raw View
------=_Part_3085_20492392.1402483612867
Content-Type: text/plain; charset=UTF-8
I desperately want this feature. I have been looking into the Rust
programming language and this one omission in C++ is the main reason.
is there enough interest or support in the world to get this as a
non-standard extension in clang or gcc?
seems like a close fork of C++ would be less work for the world than a
whole new language needing IDE support , new libraries etc. ( but at the
minute, it seems like jumping to a whole new language is the only way to
get this )
--
---
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_3085_20492392.1402483612867
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">I desperately want this feature. I have been looking into =
the Rust programming language and this one omission in C++ is the main reas=
on. <div>is there enough interest or support in the world to get this =
as a non-standard extension in clang or gcc?</div><div><br></div><div>seems=
like a close fork of C++ would be less work for the world than a whole new=
language needing IDE support , new libraries etc. ( but at the minute, it =
seems like jumping to a whole new language is the only way to get this )</d=
iv></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_3085_20492392.1402483612867--
.
Author: Andrew Tomazos <andrewtomazos@gmail.com>
Date: Wed, 11 Jun 2014 13:48:13 +0200
Raw View
--089e011609f4ec540c04fb8e049d
Content-Type: text/plain; charset=UTF-8
On Wed, Jun 11, 2014 at 12:46 PM, walter1234 <walter2bz@gmail.com> wrote:
> I desperately want this feature. I have been looking into the Rust
> programming language and this one omission in C++ is the main reason.
> is there enough interest or support in the world to get this as a
> non-standard extension in clang or gcc?
>
You don't need permission to write a clang or gcc extension. Just fork
them on github, and push the extension.
--
---
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/.
--089e011609f4ec540c04fb8e049d
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 W=
ed, Jun 11, 2014 at 12:46 PM, walter1234 <span dir=3D"ltr"><<a href=3D"m=
ailto:walter2bz@gmail.com" target=3D"_blank">walter2bz@gmail.com</a>></s=
pan> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div dir=3D"ltr">I desperately want this fea=
ture. I have been looking into the Rust programming language and this one o=
mission in C++ is the main reason.=C2=A0<div>
is there enough interest or support in the world to get this as a non-stand=
ard extension in clang or gcc?</div></div></blockquote><div><br></div><div>=
You don't need permission to write a clang or gcc extension. =C2=A0Just=
fork them on github, and push the extension.=C2=A0</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 />
--089e011609f4ec540c04fb8e049d--
.
Author: gmisocpp@gmail.com
Date: Wed, 11 Jun 2014 06:20:13 -0700 (PDT)
Raw View
------=_Part_1614_24357997.1402492813202
Content-Type: text/plain; charset=UTF-8
>
>
> As mentioned, I haven't studied the member access control issues as
> closely as I would like yet.
>
> One approach would be to newly include access-specifier as a possible
> decl-specifier, and this would provide that level of access to the
> parameter.
>
> So for example:
>
> M.h
>
> struct M
> {
>
> void add42();
>
> private:
> int i;
>
> };
>
> M.cpp
>
> static void add(private M this, int x)
> {
> i += x;
> }
>
> void M::add42()
> {
> add(42);
> }
>
> With no access-specifier, the default access level is as it is now, public.
>
> Whether such an access-specifier override would only be allowed on these
> explicit object parameters, or whether such an access override would be
> allowed orthogonally to any declaration of class type...
>
> class C { private: int x; }
> void f(private C& c) { c.x++; } // ok
>
> ...I'm not sure.
>
> The interaction with friend classes and friend functions also needs to be
> studied.
>
> Also I see the explicit object parameter feature, as well as the
> access-specifier override idea, playing well with virtual parameters and
> multi-methods: http://www.stroustrup.com/multimethods.pdf. Having a
> double-dispatch function (whether static or dynamic) with private access to
> both its object parameters is clearly desirable and sensible in a number of
> use cases.
>
> I've been playing with the idea of packaging these features all up
> together in a new major proposed feature called Free Methods, and making an
> implementation. It's not clear to me yet if there is sufficient interest.
>
>
I can see some value extension methods but I don't fully follow this
proposal yet.
Is your proposal proposing to enable the ability for people who aren't the
author of a particular class, to write a free function that grants
itself access to the private data of that class?
If so, why would that be good?
Wouldn't that just subvert what the original designer of the class wanted?
If so would that be used more often to do harm than good?
Wouldn't that then overall be a mistake to allow such a feature into the
language?
Perhaps I misunderstand things or the use case. Access to public data I can
understand, but not private.
I also think a special syntax is necessary to make such functions easily
findable.
So, in my view, something like this:
class C { private: int x; }
void f(extension C this) { this->i++; } // not ok
This way to find all extensions to class C, you just search for extension C
and you should find them all.
A designer of a class may want to use a free function for some reason to
access private data, they could use friend for that.
Non designers of the class would just not have an option and private
remains private.
It seems reasonable to grant access to protected members by default. But
extra syntax could be used.
Like void f(extension C protected this) { }
But perhaps use of protected anything shouldn't be encouraged.
What do you think?
C# has extension methods, I wonder if we should consider adding support for
partial classes too. btw.
Thanks
--
---
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_1614_24357997.1402492813202
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><blockquote class=3D"gmail_quote" style=3D"margin: 0px 0px=
0px 0.8ex; padding-left: 1ex; border-left-color: rgb(204, 204, 204); borde=
r-left-width: 1px; border-left-style: solid;"><div dir=3D"ltr"><div><br>As =
mentioned, I haven't studied the member access control issues as closely as=
I would like yet.<br><br>One approach would be to newly include access-spe=
cifier as a possible decl-specifier, and this would provide that level of a=
ccess to the parameter.<br><br>So for example:<br><br>M.h<br><br> &nbs=
p; struct M<br> {<br><br> &n=
bsp; void add42();<br><br> private:<br> =
int i;<br><br> };<br=
><br>M.cpp<br><br> static void add(private M this, int x)=
<br> {<br> i +=
=3D x;<br> }<br><br> void M::add42()<br=
> {<br> add(42)=
;<br> }<br><br>With no access-specifier, the default acce=
ss level is as it is now, public.<br><br>Whether such an access-specifier o=
verride would only be allowed on these explicit object parameters, or wheth=
er such an access override would be allowed orthogonally to any declaration=
of class type...<br><br> class C { private: int x; }<br>=
void f(private C& c) { c.x++; } // ok <br><br>...I'm=
not sure.<br><br>The interaction with friend classes and friend functions =
also needs to be studied.<br><br>Also I see the explicit object parameter f=
eature, as well as the access-specifier override idea, playing well with vi=
rtual parameters and multi-methods: <a onmousedown=3D"this.href=3D'http://w=
ww.google.com/url?q\75http%3A%2F%2Fwww.stroustrup.com%2Fmultimethods.pdf\46=
sa\75D\46sntz\0751\46usg\75AFQjCNGNT_h7jzLcsk53AbcnkSjH3PTlZw';return true;=
" onclick=3D"this.href=3D'http://www.google.com/url?q\75http%3A%2F%2Fwww.st=
roustrup.com%2Fmultimethods.pdf\46sa\75D\46sntz\0751\46usg\75AFQjCNGNT_h7jz=
Lcsk53AbcnkSjH3PTlZw';return true;" href=3D"http://www.stroustrup.com/multi=
methods.pdf" target=3D"_blank">http://www.stroustrup.com/<wbr>multimethods.=
pdf</a>. Having a double-dispatch function (whether static or dynamic=
) with private access to both its object parameters is clearly desirable an=
d sensible in a number of use cases.<br><br>I've been playing with the idea=
of packaging these features all up together in a new major proposed featur=
e called Free Methods, and making an implementation. It's not clear t=
o me yet if there is sufficient interest.<br><br></div></div></blockquote><=
div><br></div><div>I can see some value extension methods but I d=
on't fully follow this proposal yet. </div><div><br></div><div>Is your =
;proposal proposing to enable the ability for people who aren't t=
he author of a particular class, to write a free function that grants =
itself access to the private data of that class?</div><=
div><br></div><div>If so, why would that be good?</div><div><br></div><div>=
Wouldn't that just subvert what the original designer of the class wanted?<=
/div><div><br></div><div>If so would that be used more often to do har=
m than good?</div><div><br></div><div>Wouldn't that then overall be a mista=
ke to allow such a feature into the language?</div><div><br></div><div>Perh=
aps I misunderstand things or the use case. Access to public data I can und=
erstand, but not private.</div><div><br></div><div>I also think a spec=
ial syntax is necessary to make such functions easily findable.</div><=
div><br></div><div>So, in my view, something like this:</div><div><br></div=
><div> class C { private: int x; }<br> =
void f(extension C this) { this->i++; } // not ok <br></div><div><b=
r></div><div>This way to find all extensions to class C, you just search fo=
r extension C and you should find them all.</div><div><br></div><div>A desi=
gner of a class may want to use a free function for some reason to access p=
rivate data, they could use friend for that.</div><div>Non designers of the=
class would just not have an option and private remains private.</div=
><div><br></div><div>It seems reasonable to grant access to protected =
members by default. But extra syntax could be used.</div><div><br></di=
v><div>Like void f(extension C protected this) { }</div><div><br></div=
><div>But perhaps use of protected anything shouldn't be encouraged.</div><=
div><br></div><div>What do you think?</div><div><br></div><div>C# has exten=
sion methods, I wonder if we should consider adding support for partial cla=
sses too. btw.</div><div><br></div><div>Thanks</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 />
------=_Part_1614_24357997.1402492813202--
.