Topic: Have "extension methods" been proposed for C++1y?
Author: Ville Voutilainen <ville.voutilainen@gmail.com>
Date: Tue, 19 Mar 2013 22:25:05 +0200
Raw View
On 19 March 2013 22:17, Michal Mocny <little3lue@gmail.com> wrote:
> I haven't been able to find any proposal on this group for "extension
> methods". What I mean is to allow using the "object-dot-method" sytax to
> call "global-function-with-object-as-first-argument".
> I figure this must have been discussed at some point, given how many amazing
> benefits this would have combined with ranges, concepts, modules etc etc.
> Perhaps there are some serious drawbacks that have already been discussed,
> but I would love to read about them.
I can find at least
http://open-std.org/JTC1/SC22/WG21/docs/papers/2007/n2200.pdf
Overloading operator. pops up every now and then. There are various
counter-arguments
for 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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.
.
Author: little3lue <little3lue@gmail.com>
Date: Tue, 19 Mar 2013 16:29:34 -0400
Raw View
--047d7b66f619e48edc04d84cf7ba
Content-Type: text/plain; charset=ISO-8859-1
I guess I haven't considered this operator overloading. I considered this
a lowering technique, if obj.method(...) is not valid syntax, but
method(obj, ...) is, lower to that form. Though I am really just looking
at this at a surface level.
Thanks for the link, I'll read to see if it changes my mind.
-Michal
On Tue, Mar 19, 2013 at 4:25 PM, Ville Voutilainen <
ville.voutilainen@gmail.com> wrote:
> On 19 March 2013 22:17, Michal Mocny <little3lue@gmail.com> wrote:
> > I haven't been able to find any proposal on this group for "extension
> > methods". What I mean is to allow using the "object-dot-method" sytax to
> > call "global-function-with-object-as-first-argument".
> > I figure this must have been discussed at some point, given how many
> amazing
> > benefits this would have combined with ranges, concepts, modules etc etc.
> > Perhaps there are some serious drawbacks that have already been
> discussed,
> > but I would love to read about them.
>
> I can find at least
> http://open-std.org/JTC1/SC22/WG21/docs/papers/2007/n2200.pdf
>
> Overloading operator. pops up every now and then. There are various
> counter-arguments
> for it.
>
> --
>
> ---
> 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/17tP4GJbYaI/unsubscribe?hl=en
> .
> 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.
> Visit this group at
> http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.
>
>
>
--
---
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/?hl=en.
--047d7b66f619e48edc04d84cf7ba
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">I guess I haven't considered this operator overloading=
.. =A0I considered this a lowering technique, if obj.method(...) is not vali=
d syntax, but method(obj, ...) is, lower to that form. =A0Though I am reall=
y just looking at this at a surface level.<div>
<br></div><div style>Thanks for the link, I'll read to see if it change=
s my mind.</div><div style><br></div><div style>-Michal</div></div><div cla=
ss=3D"gmail_extra"><br><br><div class=3D"gmail_quote">On Tue, Mar 19, 2013 =
at 4:25 PM, Ville Voutilainen <span dir=3D"ltr"><<a href=3D"mailto:ville=
..voutilainen@gmail.com" target=3D"_blank">ville.voutilainen@gmail.com</a>&g=
t;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">On 19 March 2013 22:17, Michal Mocny <<a =
href=3D"mailto:little3lue@gmail.com">little3lue@gmail.com</a>> wrote:<br=
>
> I haven't been able to find any proposal on this group for "e=
xtension<br>
> methods". =A0What I mean is to allow using the "object-dot-m=
ethod" sytax to<br>
> call "global-function-with-object-as-first-argument".<br>
> I figure this must have been discussed at some point, given how many a=
mazing<br>
> benefits this would have combined with ranges, concepts, modules etc e=
tc.<br>
> Perhaps there are some serious drawbacks that have already been discus=
sed,<br>
> but I would love to read about them.<br>
<br>
I can find at least<br>
<a href=3D"http://open-std.org/JTC1/SC22/WG21/docs/papers/2007/n2200.pdf" t=
arget=3D"_blank">http://open-std.org/JTC1/SC22/WG21/docs/papers/2007/n2200.=
pdf</a><br>
<br>
Overloading operator. pops up every now and then. There are various<br>
counter-arguments<br>
for it.<br>
<span class=3D"HOEnZb"><font color=3D"#888888"><br>
--<br>
<br>
---<br>
You received this message because you are subscribed to a topic in the Goog=
le Groups "ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this topic, visit <a href=3D"https://groups.google.com/=
a/isocpp.org/d/topic/std-proposals/17tP4GJbYaI/unsubscribe?hl=3Den" target=
=3D"_blank">https://groups.google.com/a/isocpp.org/d/topic/std-proposals/17=
tP4GJbYaI/unsubscribe?hl=3Den</a>.<br>
To unsubscribe from this group and all its topics, send an email to <a href=
=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org">std-proposals+unsubscrib=
e@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/?hl=3Den" target=3D"_blank">http://groups.google.com/a/isocpp=
..org/group/std-proposals/?hl=3Den</a>.<br>
<br>
<br>
</font></span></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" 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/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
<br />
<br />
--047d7b66f619e48edc04d84cf7ba--
.
Author: =?ISO-8859-1?Q?Daniel_Kr=FCgler?= <daniel.kruegler@gmail.com>
Date: Tue, 19 Mar 2013 21:30:17 +0100
Raw View
2013/3/19 Ville Voutilainen <ville.voutilainen@gmail.com>:
> On 19 March 2013 22:17, Michal Mocny <little3lue@gmail.com> wrote:
>> I haven't been able to find any proposal on this group for "extension
>> methods". What I mean is to allow using the "object-dot-method" sytax to
>> call "global-function-with-object-as-first-argument".
>> I figure this must have been discussed at some point, given how many amazing
>> benefits this would have combined with ranges, concepts, modules etc etc.
>> Perhaps there are some serious drawbacks that have already been discussed,
>> but I would love to read about them.
>
> I can find at least
> http://open-std.org/JTC1/SC22/WG21/docs/papers/2007/n2200.pdf
>
> Overloading operator. pops up every now and then. There are various
> counter-arguments
> for it.
My understanding always had been that overloading operator. is a very
different thing compared to calling free functions using the dot
notation or calling member functions when using a free-style function
call.
- Daniel
--
---
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/?hl=en.
.
Author: Fernando Cacciola <fernando.cacciola@gmail.com>
Date: Tue, 19 Mar 2013 17:30:44 -0300
Raw View
--e0cb4efa6e6c39f28804d84cfd9d
Content-Type: text/plain; charset=ISO-8859-1
On Tue, Mar 19, 2013 at 5:17 PM, Michal Mocny <little3lue@gmail.com> wrote:
> I haven't been able to find any proposal on this group for "extension
> methods". What I mean is to allow using the "object-dot-method" sytax to
> call "global-function-with-object-as-first-argument".
>
> FWIW, I use extension methods in C# all the time, and *there* I find it
very useful.
OTOH, C# doesn't have free functions, so extension methods are sort of
required as the alternative is to put a static function into an
unnecessarily (and usually ugly) named struct.
But, we do have free functions in C++, so I'm really not sure if
overloading operator dot in this way would be of any real benefit. I'm not
neccesarily against it, but I would likely not be in favor of it either.
Best
--
Fernando Cacciola
SciSoft Consulting, Founder
http://www.scisoft-consulting.com
--
---
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/?hl=en.
--e0cb4efa6e6c39f28804d84cfd9d
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><br><div class=3D"gmail=
_quote">On Tue, Mar 19, 2013 at 5:17 PM, Michal Mocny <span dir=3D"ltr"><=
;<a href=3D"mailto:little3lue@gmail.com" target=3D"_blank">little3lue@gmail=
..com</a>></span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">I haven't been able to find any proposal=
on this group for "extension methods". =A0What I mean is to allo=
w using the "object-dot-method" sytax to call "global-functi=
on-with-object-as-first-argument".<div>
<br></div></blockquote><div>FWIW, I use extension methods in C# all the tim=
e, and *there* I find it very useful.<br></div><div>OTOH, C# doesn't ha=
ve free functions, so extension methods are sort of required as the alterna=
tive is to put a static function into an unnecessarily (and usually ugly) n=
amed struct.<br>
<br></div><div>But, we do have free functions in C++, so I'm really not=
sure if overloading operator dot in this way would be of any real benefit.=
I'm not neccesarily against it, but I would likely not be in favor of =
it either.<br>
<br></div><div>Best<br></div></div><br clear=3D"all"><br>-- <br>Fernando Ca=
cciola<br>SciSoft Consulting, Founder<br><a href=3D"http://www.scisoft-cons=
ulting.com">http://www.scisoft-consulting.com</a>
</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/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
<br />
<br />
--e0cb4efa6e6c39f28804d84cfd9d--
.
Author: Fernando Cacciola <fernando.cacciola@gmail.com>
Date: Tue, 19 Mar 2013 17:34:32 -0300
Raw View
--e0cb4efa6e6ccbcdd504d84d0a05
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
On Tue, Mar 19, 2013 at 5:30 PM, Daniel Kr=FCgler
<daniel.kruegler@gmail.com>wrote:
> 2013/3/19 Ville Voutilainen <ville.voutilainen@gmail.com>:
> > On 19 March 2013 22:17, Michal Mocny <little3lue@gmail.com> wrote:
> >> I haven't been able to find any proposal on this group for "extension
> >> methods". What I mean is to allow using the "object-dot-method" sytax
> to
> >> call "global-function-with-object-as-first-argument".
> >> I figure this must have been discussed at some point, given how many
> amazing
> >> benefits this would have combined with ranges, concepts, modules etc
> etc.
> >> Perhaps there are some serious drawbacks that have already been
> discussed,
> >> but I would love to read about them.
> >
> > I can find at least
> > http://open-std.org/JTC1/SC22/WG21/docs/papers/2007/n2200.pdf
> >
> > Overloading operator. pops up every now and then. There are various
> > counter-arguments
> > for it.
>
> My understanding always had been that overloading operator. is a very
> different thing compared to calling free functions using the dot
> notation or calling member functions when using a free-style function
> call.
>
> Hmm, OK, I think you are right and in any case it wouldn't be operator .
overloading but an alternative syntax.
Still, not sure I would use it. I'm not among those who consider free
functions to be less OO than member functions.
Best
--=20
Fernando Cacciola
SciSoft Consulting, Founder
http://www.scisoft-consulting.com
--=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/?hl=3Den.
--e0cb4efa6e6ccbcdd504d84d0a05
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On T=
ue, Mar 19, 2013 at 5:30 PM, Daniel Kr=FCgler <span dir=3D"ltr"><<a href=
=3D"mailto:daniel.kruegler@gmail.com" target=3D"_blank">daniel.kruegler@gma=
il.com</a>></span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">2013/3/19 Ville Voutilainen <<a href=3D"m=
ailto:ville.voutilainen@gmail.com">ville.voutilainen@gmail.com</a>>:<br>
<div class=3D"im">> On 19 March 2013 22:17, Michal Mocny <<a href=3D"=
mailto:little3lue@gmail.com">little3lue@gmail.com</a>> wrote:<br>
>> I haven't been able to find any proposal on this group for &qu=
ot;extension<br>
>> methods". =A0What I mean is to allow using the "object-d=
ot-method" sytax to<br>
>> call "global-function-with-object-as-first-argument".<br=
>
>> I figure this must have been discussed at some point, given how ma=
ny amazing<br>
>> benefits this would have combined with ranges, concepts, modules e=
tc etc.<br>
>> Perhaps there are some serious drawbacks that have already been di=
scussed,<br>
>> but I would love to read about them.<br>
><br>
> I can find at least<br>
> <a href=3D"http://open-std.org/JTC1/SC22/WG21/docs/papers/2007/n2200.p=
df" target=3D"_blank">http://open-std.org/JTC1/SC22/WG21/docs/papers/2007/n=
2200.pdf</a><br>
><br>
> Overloading operator. pops up every now and then. There are various<br=
>
> counter-arguments<br>
> for it.<br>
<br>
</div>My understanding always had been that overloading operator. is a very=
<br>
different thing compared to calling free functions using the dot<br>
notation or calling member functions when using a free-style function<br>
call.<br>
<span class=3D"HOEnZb"><font color=3D"#888888"><br></font></span></blockquo=
te><div>Hmm, OK, I think you are right and in any case it wouldn't be o=
perator=A0 . overloading but an alternative syntax.<br><br></div><div>Still=
, not sure I would use it. I'm not among those who consider free functi=
ons to be less OO than member functions.<br>
<br></div><div>Best<br><br><br>-- <br></div></div>Fernando Cacciola<br>SciS=
oft Consulting, Founder<br><a href=3D"http://www.scisoft-consulting.com">ht=
tp://www.scisoft-consulting.com</a>
</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/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
<br />
<br />
--e0cb4efa6e6ccbcdd504d84d0a05--
.
Author: Ville Voutilainen <ville.voutilainen@gmail.com>
Date: Tue, 19 Mar 2013 22:43:05 +0200
Raw View
On 19 March 2013 22:34, Fernando Cacciola <fernando.cacciola@gmail.com> wrote:
> Hmm, OK, I think you are right and in any case it wouldn't be operator .
> overloading but an alternative syntax.
The unified call syntax also pops up every now and then, but I can't
easily find a proposal
for it. It was mentioned as one potential issue to fix in the Portland
Evolution meetings,
but I haven't seen follow-up papers that would 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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.
.
Author: little3lue <little3lue@gmail.com>
Date: Tue, 19 Mar 2013 16:43:57 -0400
Raw View
--047d7b6247be53e58904d84d2b2a
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Its not a matter of less/more OO, its a matter of convenience. I think it
is not hard to argue that dot syntax chaining is easier to read.
Also, I've been thinking this would be useful as far back as reading Herb
discuss free functions in std::string (http://www.gotw.ca/gotw/084.htm).
We polluted std::string class because users expected methods to be
available using the dot syntax.
Another example: std::swap
For any generic type you could do:
using std::swap;
foo.swap(bar);
If a member swap is available use it, if a free function swap overloaded
for T is available, use it, otherwise, use generic std::swap.
Another example: N3582 (Return type deduction for normal functions) starts
the paper off comparing member functions and free functions and how
developers like to provide definitions as free functions etc.
If functions that rely only on public interface of a class could be written
as free functions, without library author having to document functionality
according to call style, that would be a huge win.
In the future, modules could even allow this style for private access.
-Michal
On Tue, Mar 19, 2013 at 4:34 PM, Fernando Cacciola <
fernando.cacciola@gmail.com> wrote:
> On Tue, Mar 19, 2013 at 5:30 PM, Daniel Kr=FCgler <daniel.kruegler@gmail.=
com
> > wrote:
>
>> 2013/3/19 Ville Voutilainen <ville.voutilainen@gmail.com>:
>> > On 19 March 2013 22:17, Michal Mocny <little3lue@gmail.com> wrote:
>> >> I haven't been able to find any proposal on this group for "extension
>> >> methods". What I mean is to allow using the "object-dot-method" syta=
x
>> to
>> >> call "global-function-with-object-as-first-argument".
>> >> I figure this must have been discussed at some point, given how many
>> amazing
>> >> benefits this would have combined with ranges, concepts, modules etc
>> etc.
>> >> Perhaps there are some serious drawbacks that have already been
>> discussed,
>> >> but I would love to read about them.
>> >
>> > I can find at least
>> > http://open-std.org/JTC1/SC22/WG21/docs/papers/2007/n2200.pdf
>> >
>> > Overloading operator. pops up every now and then. There are various
>> > counter-arguments
>> > for it.
>>
>> My understanding always had been that overloading operator. is a very
>> different thing compared to calling free functions using the dot
>> notation or calling member functions when using a free-style function
>> call.
>>
>> Hmm, OK, I think you are right and in any case it wouldn't be operator =
..
> overloading but an alternative syntax.
>
> Still, not sure I would use it. I'm not among those who consider free
> functions to be less OO than member functions.
>
> Best
>
>
> --
> Fernando Cacciola
> SciSoft Consulting, Founder
> http://www.scisoft-consulting.com
>
> --
>
> ---
> 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/17tP4GJbYaI/=
unsubscribe?hl=3Den
> .
> 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.
> Visit this group at
> http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=3Den.
>
>
>
--=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/?hl=3Den.
--047d7b6247be53e58904d84d2b2a
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Its not a matter of less/more OO, its a matter of convenie=
nce. =A0I think it is not hard to argue that dot syntax chaining is easier =
to read.<div><br></div><div>Also, I've been thinking this would be usef=
ul as far back as reading Herb discuss free functions in std::string (<a hr=
ef=3D"http://www.gotw.ca/gotw/084.htm">http://www.gotw.ca/gotw/084.htm</a>)=
..</div>
<div><br></div><div style>We polluted std::string class because users expec=
ted methods to be available using the dot syntax.</div><div style><br></div=
><div style>Another example: std::swap</div><div style><br></div><div style=
>
For any generic type you could do:</div><div style>using std::swap;</div><d=
iv style>foo.swap(bar);</div><div style><br></div><div style>If a member sw=
ap is available use it, if a free function swap overloaded for T is availab=
le, use it, otherwise, use generic std::swap.</div>
<div style><br></div><div style>Another example:=A0N3582 (Return type deduc=
tion for normal functions) starts the paper off comparing member functions =
and free functions and how developers like to provide definitions as free f=
unctions etc.</div>
<div style><br></div><div style>If functions that rely only on public inter=
face of a class could be written as free functions, without library author =
having to document functionality according to call style, that would be a h=
uge win.</div>
<div style>In the future, modules could even allow this style for private a=
ccess.</div><div style><br></div><div style>-Michal</div></div><div class=
=3D"gmail_extra"><br><br><div class=3D"gmail_quote">On Tue, Mar 19, 2013 at=
4:34 PM, Fernando Cacciola <span dir=3D"ltr"><<a href=3D"mailto:fernand=
o.cacciola@gmail.com" target=3D"_blank">fernando.cacciola@gmail.com</a>>=
</span> 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"><div class=3D"gmail_extra">=
<div class=3D"gmail_quote"><div class=3D"im">On Tue, Mar 19, 2013 at 5:30 P=
M, Daniel Kr=FCgler <span dir=3D"ltr"><<a href=3D"mailto:daniel.kruegler=
@gmail.com" target=3D"_blank">daniel.kruegler@gmail.com</a>></span> wrot=
e:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">2013/3/19 Ville Voutilainen <<a href=3D"m=
ailto:ville.voutilainen@gmail.com" target=3D"_blank">ville.voutilainen@gmai=
l.com</a>>:<br>
<div>> On 19 March 2013 22:17, Michal Mocny <<a href=3D"mailto:little=
3lue@gmail.com" target=3D"_blank">little3lue@gmail.com</a>> wrote:<br>
>> I haven't been able to find any proposal on this group for &qu=
ot;extension<br>
>> methods". =A0What I mean is to allow using the "object-d=
ot-method" sytax to<br>
>> call "global-function-with-object-as-first-argument".<br=
>
>> I figure this must have been discussed at some point, given how ma=
ny amazing<br>
>> benefits this would have combined with ranges, concepts, modules e=
tc etc.<br>
>> Perhaps there are some serious drawbacks that have already been di=
scussed,<br>
>> but I would love to read about them.<br>
><br>
> I can find at least<br>
> <a href=3D"http://open-std.org/JTC1/SC22/WG21/docs/papers/2007/n2200.p=
df" target=3D"_blank">http://open-std.org/JTC1/SC22/WG21/docs/papers/2007/n=
2200.pdf</a><br>
><br>
> Overloading operator. pops up every now and then. There are various<br=
>
> counter-arguments<br>
> for it.<br>
<br>
</div>My understanding always had been that overloading operator. is a very=
<br>
different thing compared to calling free functions using the dot<br>
notation or calling member functions when using a free-style function<br>
call.<br>
<span><font color=3D"#888888"><br></font></span></blockquote></div><div>Hmm=
, OK, I think you are right and in any case it wouldn't be operator=A0 =
.. overloading but an alternative syntax.<br><br></div><div>Still, not sure =
I would use it. I'm not among those who consider free functions to be l=
ess OO than member functions.<br>
<br></div><div>Best<span class=3D"HOEnZb"><font color=3D"#888888"><br><br><=
br>-- <br></font></span></div></div><div class=3D"im">Fernando Cacciola<br>=
SciSoft Consulting, Founder<br><a href=3D"http://www.scisoft-consulting.com=
" target=3D"_blank">http://www.scisoft-consulting.com</a>
</div></div></div>
<p></p>
-- <br><div class=3D"HOEnZb"><div class=3D"h5">
=A0<br>
--- <br>
You received this message because you are subscribed to a topic in the Goog=
le Groups "ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this topic, visit <a href=3D"https://groups.google.com/=
a/isocpp.org/d/topic/std-proposals/17tP4GJbYaI/unsubscribe?hl=3Den" target=
=3D"_blank">https://groups.google.com/a/isocpp.org/d/topic/std-proposals/17=
tP4GJbYaI/unsubscribe?hl=3Den</a>.<br>
To unsubscribe from this group and all its topics, send an email to <a href=
=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org" target=3D"_blank">std-pr=
oposals+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>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den" target=3D"_blank">http://groups.google.com/a/isocpp=
..org/group/std-proposals/?hl=3Den</a>.<br>
=A0<br>
=A0<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" 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/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
<br />
<br />
--047d7b6247be53e58904d84d2b2a--
.
Author: little3lue <little3lue@gmail.com>
Date: Tue, 19 Mar 2013 16:45:22 -0400
Raw View
--047d7b603c1c5ac98c04d84d305f
Content-Type: text/plain; charset=ISO-8859-1
Ville,
So if a paper was written, we don't know for certain that it would be
rejected?
I was basically looking to answer that question.
Thanks!
-Michal
On Tue, Mar 19, 2013 at 4:43 PM, Ville Voutilainen <
ville.voutilainen@gmail.com> wrote:
> On 19 March 2013 22:34, Fernando Cacciola <fernando.cacciola@gmail.com>
> wrote:
> > Hmm, OK, I think you are right and in any case it wouldn't be operator .
> > overloading but an alternative syntax.
>
> The unified call syntax also pops up every now and then, but I can't
> easily find a proposal
> for it. It was mentioned as one potential issue to fix in the Portland
> Evolution meetings,
> but I haven't seen follow-up papers that would propose it.
>
> --
>
> ---
> 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/17tP4GJbYaI/unsubscribe?hl=en
> .
> 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.
> Visit this group at
> http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.
>
>
>
--
---
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/?hl=en.
--047d7b603c1c5ac98c04d84d305f
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Ville,<div><br></div><div>So if a paper was written, we do=
n't know for certain that it would be rejected?</div><div style>I was b=
asically looking to answer that question.</div><div><br></div><div style>Th=
anks!</div>
<div style>-Michal</div></div><div class=3D"gmail_extra"><br><br><div class=
=3D"gmail_quote">On Tue, Mar 19, 2013 at 4:43 PM, Ville Voutilainen <span d=
ir=3D"ltr"><<a href=3D"mailto:ville.voutilainen@gmail.com" target=3D"_bl=
ank">ville.voutilainen@gmail.com</a>></span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div class=3D"im">On 19 March 2013 22:34, Fe=
rnando Cacciola <<a href=3D"mailto:fernando.cacciola@gmail.com">fernando=
..cacciola@gmail.com</a>> wrote:<br>
> Hmm, OK, I think you are right and in any case it wouldn't be oper=
ator =A0.<br>
> overloading but an alternative syntax.<br>
<br>
</div>The unified call syntax also pops up every now and then, but I can=
9;t<br>
easily find a proposal<br>
for it. It was mentioned as one potential issue to fix in the Portland<br>
Evolution meetings,<br>
but I haven't seen follow-up papers that would propose it.<br>
<div class=3D"HOEnZb"><div class=3D"h5"><br>
--<br>
<br>
---<br>
You received this message because you are subscribed to a topic in the Goog=
le Groups "ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this topic, visit <a href=3D"https://groups.google.com/=
a/isocpp.org/d/topic/std-proposals/17tP4GJbYaI/unsubscribe?hl=3Den" target=
=3D"_blank">https://groups.google.com/a/isocpp.org/d/topic/std-proposals/17=
tP4GJbYaI/unsubscribe?hl=3Den</a>.<br>
To unsubscribe from this group and all its topics, send an email to <a href=
=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org">std-proposals+unsubscrib=
e@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/?hl=3Den" target=3D"_blank">http://groups.google.com/a/isocpp=
..org/group/std-proposals/?hl=3Den</a>.<br>
<br>
<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" 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/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
<br />
<br />
--047d7b603c1c5ac98c04d84d305f--
.
Author: Ville Voutilainen <ville.voutilainen@gmail.com>
Date: Wed, 20 Mar 2013 00:22:42 +0200
Raw View
On 19 March 2013 22:45, little3lue <little3lue@gmail.com> wrote:
> So if a paper was written, we don't know for certain that it would be
> rejected?
> I was basically looking to answer that question.
We don't know that, no. There has been some interest in this issue amongst
the Evolution Working Group, so I'd expect a paper to be considered as
a potential
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/?hl=en.
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Tue, 19 Mar 2013 15:39:44 -0700 (PDT)
Raw View
------=_Part_1002_24293020.1363732784013
Content-Type: text/plain; charset=ISO-8859-1
On Tuesday, March 19, 2013 1:17:04 PM UTC-7, Michal Mocny wrote:
>
> I haven't been able to find any proposal on this group for "extension
> methods". What I mean is to allow using the "object-dot-method" sytax to
> call "global-function-with-object-as-first-argument".
>
> i.e.
>
> using std::sort;
> my_vector.sort();
> // or
> my_vector.std::sort();
>
> // especially powerful with chaining, if globals return the target object
> my_vector.sort().tail(10).copy(ostream_iterator...)
> //or
>
> my_vector.sort(std::greater()).head(10).inverted().copy(ostream_iterator...)
>
> etc etc
>
>
> I figure this must have been discussed at some point, given how many
> amazing benefits this would have combined with ranges, concepts, modules
> etc etc. Perhaps there are some serious drawbacks that have already been
> discussed, but I would love to read about them.
>
> Thanks.
>
Using Boost.Range, you can do this (assuming you did a `using
boost::range`):
copy(sort(my_vector) | slice(0, 9) | reversed(), ostream_iterator...);
Personally, I like this better, as it has a clear separation between
algorithms (things that care about the data) and adapters (things that play
with the range itself, while leaving the data alone).
--
---
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/?hl=en.
------=_Part_1002_24293020.1363732784013
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<br><br>On Tuesday, March 19, 2013 1:17:04 PM UTC-7, Michal Mocny wrote:<bl=
ockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border=
-left: 1px #ccc solid;padding-left: 1ex;">I haven't been able to find any p=
roposal on this group for "extension methods". What I mean is to allo=
w using the "object-dot-method" sytax to call "global-function-with-object-=
<wbr>as-first-argument".<div><br></div><div>i.e.</div><div><br></div><div>u=
sing std::sort;</div><div>my_vector.sort();</div><div>// or<br></div><div>m=
y_vector.std::sort();</div><div><br></div><div>// especially powerful with =
chaining, if globals return the target object</div><div>my_vector.sort().ta=
il(10).<wbr>copy(ostream_iterator...)</div><div>//or</div><div>my_vector.so=
rt(std::greater())<wbr>.head(10).inverted().copy(<wbr>ostream_iterator...)<=
/div><div><br></div><div>etc etc</div><div><br></div><div><br></div><div>I =
figure this must have been discussed at some point, given how many amazing =
benefits this would have combined with ranges, concepts, modules etc etc. &=
nbsp;Perhaps there are some serious drawbacks that have already been discus=
sed, but I would love to read about them.</div><div><br>Thanks.</div></bloc=
kquote><div><br>Using Boost.Range, you can do this (assuming you did a `usi=
ng boost::range`):<br><br><div class=3D"prettyprint" style=3D"background-co=
lor: rgb(250, 250, 250); border-color: rgb(187, 187, 187); border-style: so=
lid; 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">copy</span><span style=3D"color: #660;" class=3D"styled-by-pr=
ettify">(</span><span style=3D"color: #000;" class=3D"styled-by-prettify">s=
ort</span><span style=3D"color: #660;" class=3D"styled-by-prettify">(</span=
><span style=3D"color: #000;" class=3D"styled-by-prettify">my_vector</span>=
<span style=3D"color: #660;" class=3D"styled-by-prettify">)</span><span sty=
le=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"col=
or: #660;" class=3D"styled-by-prettify">|</span><span style=3D"color: #000;=
" class=3D"styled-by-prettify"> slice</span><span style=3D"color: #660;" cl=
ass=3D"styled-by-prettify">(</span><span style=3D"color: #066;" class=3D"st=
yled-by-prettify">0</span><span style=3D"color: #660;" class=3D"styled-by-p=
rettify">,</span><span style=3D"color: #000;" class=3D"styled-by-prettify">=
</span><span style=3D"color: #066;" class=3D"styled-by-prettify">9</span><=
span style=3D"color: #660;" class=3D"styled-by-prettify">)</span><span styl=
e=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"colo=
r: #660;" class=3D"styled-by-prettify">|</span><span style=3D"color: #000;"=
class=3D"styled-by-prettify"> reversed</span><span style=3D"color: #660;" =
class=3D"styled-by-prettify">(),</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> ostream_iterator</span><span style=3D"color: #660;=
" class=3D"styled-by-prettify">...);</span><span style=3D"color: #000;" cla=
ss=3D"styled-by-prettify"><br></span></div></code></div><br>Personally, I l=
ike this better, as it has a clear separation between algorithms (things th=
at care about the data) and adapters (things that play with the range itsel=
f, while leaving the data alone).<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 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/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
<br />
<br />
------=_Part_1002_24293020.1363732784013--
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Tue, 19 Mar 2013 16:10:58 -0700 (PDT)
Raw View
------=_Part_245_326659.1363734658709
Content-Type: text/plain; charset=ISO-8859-1
On Tuesday, March 19, 2013 1:17:04 PM UTC-7, Michal Mocny wrote:
>
> I haven't been able to find any proposal on this group for "extension
> methods". What I mean is to allow using the "object-dot-method" sytax to
> call "global-function-with-object-as-first-argument".
>
> i.e.
>
> using std::sort;
> my_vector.sort();
> // or
> my_vector.std::sort();
>
> // especially powerful with chaining, if globals return the target object
> my_vector.sort().tail(10).copy(ostream_iterator...)
> //or
>
> my_vector.sort(std::greater()).head(10).inverted().copy(ostream_iterator...)
>
> etc etc
>
>
> I figure this must have been discussed at some point, given how many
> amazing benefits this would have combined with ranges, concepts, modules
> etc etc. Perhaps there are some serious drawbacks that have already been
> discussed, but I would love to read about them.
>
> Thanks.
>
If you do decide to move forward with a proposal, here are what I consider
to be key questions/hurdles you need to answer/leap:
1: What are the conditions that provoke this behavior? Does it kick in when
a member function of that name doesn't exist in the type or if the
parameter list doesn't match against the available members? What about
accessibility; if there's a private member that this code doesn't have the
right to access, will it kick in there?
Why did you pick the one you picked?
2: Does it work with ->? If not, why not? If so, what exactly is the type
passed to the function in question? If you have this:
struct T {};
void Func(T &t);
void Func(T *t);
T *t = ...
t->Func();
Which overload will be called? Why did you pick that overload instead of
the other one?
3: I assume that ADL will work on these, yes? That is, the syntax of
`s.func()` is exactly equivalent to `func(s)`, once the feature decides to
kick in.
4: Can the function name include namespace qualifiers? Not everyone throws
`using` qualifiers everywhere.
--
---
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/?hl=en.
------=_Part_245_326659.1363734658709
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
On Tuesday, March 19, 2013 1:17:04 PM UTC-7, Michal Mocny wrote:<blockquote=
class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1=
px #ccc solid;padding-left: 1ex;">I haven't been able to find any proposal =
on this group for "extension methods". What I mean is to allow using =
the "object-dot-method" sytax to call "global-function-with-object-<wbr>as-=
first-argument".<div><br></div><div>i.e.</div><div><br></div><div>using std=
::sort;</div><div>my_vector.sort();</div><div>// or<br></div><div>my_vector=
..std::sort();</div><div><br></div><div>// especially powerful with chaining=
, if globals return the target object</div><div>my_vector.sort().tail(10).<=
wbr>copy(ostream_iterator...)</div><div>//or</div><div>my_vector.sort(std::=
greater())<wbr>.head(10).inverted().copy(<wbr>ostream_iterator...)</div><di=
v><br></div><div>etc etc</div><div><br></div><div><br></div><div>I figure t=
his must have been discussed at some point, given how many amazing benefits=
this would have combined with ranges, concepts, modules etc etc. Per=
haps there are some serious drawbacks that have already been discussed, but=
I would love to read about them.</div><div><br>Thanks.</div></blockquote><=
div><br>If you do decide to move forward with a proposal, here are what I c=
onsider to be key questions/hurdles you need to answer/leap:<br><br>1: What=
are the conditions that provoke this behavior? Does it kick in when a memb=
er function of that name doesn't exist in the type or if the parameter list=
doesn't match against the available members? What about accessibility; if =
there's a private member that this code doesn't have the right to access, w=
ill it kick in there?<br><br>Why did you pick the one you picked?<br><br>2:=
Does it work with ->? If not, why not? If so, what exactly is the type =
passed to the function in question? If you have this:<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: #008;" class=3D"styled-by-prettify">struct</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"> T </span><span style=3D"col=
or: #660;" class=3D"styled-by-prettify">{};</span><span style=3D"color: #00=
0;" class=3D"styled-by-prettify"><br><br></span><span style=3D"color: #008;=
" class=3D"styled-by-prettify">void</span><span style=3D"color: #000;" clas=
s=3D"styled-by-prettify"> </span><span style=3D"color: #606;" class=3D"styl=
ed-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"=
>T </span><span style=3D"color: #660;" class=3D"styled-by-prettify">&</=
span><span style=3D"color: #000;" class=3D"styled-by-prettify">t</span><spa=
n 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"co=
lor: #008;" class=3D"styled-by-prettify">void</span><span style=3D"color: #=
000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #606;" cla=
ss=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">T </span><span style=3D"color: #660;" class=3D"styled-by-prettif=
y">*</span><span style=3D"color: #000;" class=3D"styled-by-prettify">t</spa=
n><span style=3D"color: #660;" class=3D"styled-by-prettify">);</span><span =
style=3D"color: #000;" class=3D"styled-by-prettify"><br><br>T </span><span =
style=3D"color: #660;" class=3D"styled-by-prettify">*</span><span style=3D"=
color: #000;" class=3D"styled-by-prettify">t </span><span style=3D"color: #=
660;" class=3D"styled-by-prettify">=3D</span><span style=3D"color: #000;" c=
lass=3D"styled-by-prettify"> </span><span style=3D"color: #660;" class=3D"s=
tyled-by-prettify">...</span><span style=3D"color: #000;" class=3D"styled-b=
y-prettify"><br>t</span><span style=3D"color: #660;" class=3D"styled-by-pre=
ttify">-></span><span style=3D"color: #606;" 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>=
</div></code></div><br>Which overload will be called? Why did you pick that=
overload instead of the other one?<br><br>3: I assume that ADL will work o=
n these, yes? That is, the syntax of `s.func()` is exactly equivalent to `f=
unc(s)`, once the feature decides to kick in.<br><br>4: Can the function na=
me include namespace qualifiers? Not everyone throws `using` qualifiers eve=
rywhere.<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 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/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
<br />
<br />
------=_Part_245_326659.1363734658709--
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Fri, 22 Mar 2013 04:50:25 -0700 (PDT)
Raw View
------=_Part_518_6212725.1363953025988
Content-Type: text/plain; charset=ISO-8859-1
On Tuesday, March 19, 2013 1:17:04 PM UTC-7, Michal Mocny wrote:
>
> I haven't been able to find any proposal on this group for "extension
> methods". What I mean is to allow using the "object-dot-method" sytax to
> call "global-function-with-object-as-first-argument".
>
> i.e.
>
> using std::sort;
> my_vector.sort();
> // or
> my_vector.std::sort();
>
> // especially powerful with chaining, if globals return the target object
> my_vector.sort().tail(10).copy(ostream_iterator...)
> //or
>
> my_vector.sort(std::greater()).head(10).inverted().copy(ostream_iterator...)
>
> etc etc
>
>
> I figure this must have been discussed at some point, given how many
> amazing benefits this would have combined with ranges, concepts, modules
> etc etc. Perhaps there are some serious drawbacks that have already been
> discussed, but I would love to read about them.
>
> Thanks.
>
I don't know. This seems to be way too prone to problems. It seems to me
that a much more reasonable solution to this is to just allow people to add
public member functions to an already existing class. They would *not* have
the same protection rights as actual members of the class.
Maybe just something as simple as:
class ClassName extension FuncDeclaration;
This declares that the given function can be accessed as though it were a
public member. It is still defined as a non-member function, so it wouldn't
actually be a member. It would just look like one.
It seems to me that this would solve a lot of the apparent problems. It
prevents random functions from being accidentally introduced into a class's
interface. Plus, there's already discussion floating around about being
able to designate a function as part of a class's interface, so as to match
with certain other functionality. This could probably combine well with
that.
--
---
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/?hl=en.
------=_Part_518_6212725.1363953025988
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
On Tuesday, March 19, 2013 1:17:04 PM UTC-7, Michal Mocny wrote:<blockquote=
class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1=
px #ccc solid;padding-left: 1ex;">I haven't been able to find any proposal =
on this group for "extension methods". What I mean is to allow using =
the "object-dot-method" sytax to call "global-function-with-object-<wbr>as-=
first-argument".<div><br></div><div>i.e.</div><div><br></div><div>using std=
::sort;</div><div>my_vector.sort();</div><div>// or<br></div><div>my_vector=
..std::sort();</div><div><br></div><div>// especially powerful with chaining=
, if globals return the target object</div><div>my_vector.sort().tail(10).<=
wbr>copy(ostream_iterator...)</div><div>//or</div><div>my_vector.sort(std::=
greater())<wbr>.head(10).inverted().copy(<wbr>ostream_iterator...)</div><di=
v><br></div><div>etc etc</div><div><br></div><div><br></div><div>I figure t=
his must have been discussed at some point, given how many amazing benefits=
this would have combined with ranges, concepts, modules etc etc. Per=
haps there are some serious drawbacks that have already been discussed, but=
I would love to read about them.</div><div><br>Thanks.</div></blockquote><=
div><br>I don't know. This seems to be way too prone to problems. It seems =
to me that a much more reasonable solution to this is to just allow people =
to add public member functions to an already existing class. They would <i>=
not</i> have the same protection rights as actual members of the class.<br>=
<br>Maybe just something as simple as:<br><br><div class=3D"prettyprint" st=
yle=3D"background-color: rgb(250, 250, 250); border-color: rgb(187, 187, 18=
7); border-style: solid; border-width: 1px; word-wrap: break-word;"><code c=
lass=3D"prettyprint"><div class=3D"subprettyprint"><span style=3D"color: #0=
08;" class=3D"styled-by-prettify">class</span><span style=3D"color: #000;" =
class=3D"styled-by-prettify"> </span><span style=3D"color: #606;" class=3D"=
styled-by-prettify">ClassName</span><span style=3D"color: #000;" class=3D"s=
tyled-by-prettify"> extension </span><span style=3D"color: #606;" class=3D"=
styled-by-prettify">FuncDeclaration</span><span style=3D"color: #660;" clas=
s=3D"styled-by-prettify">;</span><span style=3D"color: #000;" class=3D"styl=
ed-by-prettify"><br></span></div></code></div><br>This declares that the gi=
ven function can be accessed as though it were a public member. It is still=
defined as a non-member function, so it wouldn't actually be a member. It =
would just look like one.<br><br>It seems to me that this would solve a lot=
of the apparent problems. It prevents random functions from being accident=
ally introduced into a class's interface. Plus, there's already discussion =
floating around about being able to designate a function as part of a class=
's interface, so as to match with certain other functionality. This could p=
robably combine well with that.<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 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/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
<br />
<br />
------=_Part_518_6212725.1363953025988--
.
Author: stackmachine@hotmail.com
Date: Sat, 23 Mar 2013 15:45:30 -0700 (PDT)
Raw View
------=_Part_1787_31455107.1364078730268
Content-Type: text/plain; charset=ISO-8859-1
How about the following?
void foo(Foo* this, ...); // explicit this parameter
--
---
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/?hl=en.
------=_Part_1787_31455107.1364078730268
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
How about the following?<br><div class=3D"prettyprint" style=3D"background-=
color: rgb(250, 250, 250); border-color: rgb(187, 187, 187); border-style: =
solid; border-width: 1px; word-wrap: break-word;"><code class=3D"prettyprin=
t"><div class=3D"subprettyprint"><span style=3D"color: #008;" class=3D"styl=
ed-by-prettify">void</span><span style=3D"color: #000;" class=3D"styled-by-=
prettify"> foo</span><span style=3D"color: #660;" class=3D"styled-by-pretti=
fy">(</span><span style=3D"color: #606;" class=3D"styled-by-prettify">Foo</=
span><span style=3D"color: #660;" class=3D"styled-by-prettify">*</span><spa=
n style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=
=3D"color: #008;" class=3D"styled-by-prettify">this</span><span style=3D"co=
lor: #660;" class=3D"styled-by-prettify">,</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"s=
tyled-by-prettify"> </span><span style=3D"color: #800;" class=3D"styled-by-=
prettify">// explicit this parameter</span><span style=3D"color: #000;" cla=
ss=3D"styled-by-prettify"><br></span></div></code></div><br><br>
<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/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
<br />
<br />
------=_Part_1787_31455107.1364078730268--
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Sat, 23 Mar 2013 19:06:48 -0700 (PDT)
Raw View
------=_Part_927_29966565.1364090808034
Content-Type: text/plain; charset=ISO-8859-1
On Saturday, March 23, 2013 3:45:30 PM UTC-7, stackm...@hotmail.com wrote:
>
> How about the following?
> void foo(Foo* this, ...); // explicit this parameter
>
>
>
I personally am not comfortable with any syntactic construct where function
parameter names have non-obvious ramifications. Such as, for example adding
a function to a class's interface. Also, there's the question of how `this`
behaves, since it's a keyword. Does it mean that `foo` gets to use members
of `Foo` as though it were a member function? Does it get private access
too?
--
---
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/?hl=en.
------=_Part_927_29966565.1364090808034
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
On Saturday, March 23, 2013 3:45:30 PM UTC-7, stackm...@hotmail.com wrote:<=
blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;bord=
er-left: 1px #ccc solid;padding-left: 1ex;">How about the following?<br><di=
v style=3D"background-color:rgb(250,250,250);border-color:rgb(187,187,187);=
border-style:solid;border-width:1px;word-wrap:break-word"><code><div><span =
style=3D"color:#008">void</span><span style=3D"color:#000"> foo</span><span=
style=3D"color:#660">(</span><span style=3D"color:#606">Foo</span><span st=
yle=3D"color:#660">*</span><span style=3D"color:#000"> </span><span style=
=3D"color:#008">this</span><span style=3D"color:#660">,</span><span style=
=3D"color:#000"> </span><span style=3D"color:#660">...);</span><span style=
=3D"color:#000"> </span><span style=3D"color:#800">// explicit this paramet=
er</span><span style=3D"color:#000"><br></span></div></code></div><br><br><=
/blockquote><div><br>I personally am not comfortable with any syntactic con=
struct where function parameter names have non-obvious ramifications. Such =
as, for example adding a function to a class's interface. Also, there's the=
question of how `this` behaves, since it's a keyword. Does it mean that `f=
oo` gets to use members of `Foo` as though it were a member function? Does =
it get private access too?<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 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/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
<br />
<br />
------=_Part_927_29966565.1364090808034--
.
Author: stackmachine@hotmail.com
Date: Sun, 24 Mar 2013 13:12:49 -0700 (PDT)
Raw View
------=_Part_295_1837538.1364155969650
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Am Sonntag, 24. M=E4rz 2013 03:06:48 UTC+1 schrieb Nicol Bolas:
>
> On Saturday, March 23, 2013 3:45:30 PM UTC-7, stackm...@hotmail.com wrote=
:
>>
>> How about the following?
>> void foo(Foo* this, ...); // explicit this parameter
>>
>>
>>
> I personally am not comfortable with any syntactic construct where=20
> function parameter names have non-obvious ramifications. Such as, for=20
> example adding a function to a class's interface. Also, there's the=20
> question of how `this` behaves, since it's a keyword.
>
I like this syntax *because* it does not differ much from a function=20
declaration. It emphasizes that member functions are functions with an=20
implicit this parameter.
=20
> Does it mean that `foo` gets to use members of `Foo` as though it were a=
=20
> member function?
>
Yes.
Does it get private access too?
>
No. Only public (and possibly protected?) access.=20
--=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/?hl=3Den.
------=_Part_295_1837538.1364155969650
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<br><br>Am Sonntag, 24. M=E4rz 2013 03:06:48 UTC+1 schrieb Nicol Bolas:<blo=
ckquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-=
left: 1px #ccc solid;padding-left: 1ex;">On Saturday, March 23, 2013 3:45:3=
0 PM UTC-7, <a>stackm...@hotmail.com</a> wrote:<blockquote class=3D"gmail_q=
uote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;paddin=
g-left:1ex">How about the following?<br><div style=3D"background-color:rgb(=
250,250,250);border-color:rgb(187,187,187);border-style:solid;border-width:=
1px;word-wrap:break-word"><code><div><span style=3D"color:#008">void</span>=
<span style=3D"color:#000"> foo</span><span style=3D"color:#660">(</span><s=
pan style=3D"color:#606">Foo</span><span style=3D"color:#660">*</span><span=
style=3D"color:#000"> </span><span style=3D"color:#008">this</span><span s=
tyle=3D"color:#660">,</span><span style=3D"color:#000"> </span><span style=
=3D"color:#660">...);</span><span style=3D"color:#000"> </span><span style=
=3D"color:#800">// explicit this parameter</span><span style=3D"color:#000"=
><br></span></div></code></div><br><br></blockquote><div><br>I personally a=
m not comfortable with any syntactic construct where function parameter nam=
es have non-obvious ramifications. Such as, for example adding a function t=
o a class's interface. Also, there's the question of how `this` behaves, si=
nce it's a keyword.</div></blockquote><div>I like this syntax *because* it =
does not differ much from a function declaration. It emphasizes that member=
functions are functions with an implicit this parameter.<br> </div><b=
lockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;borde=
r-left: 1px #ccc solid;padding-left: 1ex;"><div>Does it mean that `foo` get=
s to use members of `Foo` as though it were a member function?</div></block=
quote><div> Yes.<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>Does it get private access too?<br></div></blockquote><div>No. O=
nly public (and possibly protected?) access. <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 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/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
<br />
<br />
------=_Part_295_1837538.1364155969650--
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Sun, 24 Mar 2013 13:50:57 -0700 (PDT)
Raw View
------=_Part_835_12362102.1364158257179
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
On Sunday, March 24, 2013 1:12:49 PM UTC-7, stackm...@hotmail.com wrote:
>
>
>
> Am Sonntag, 24. M=E4rz 2013 03:06:48 UTC+1 schrieb Nicol Bolas:
>>
>> On Saturday, March 23, 2013 3:45:30 PM UTC-7, stackm...@hotmail.comwrote=
:
>>>
>>> How about the following?
>>> void foo(Foo* this, ...); // explicit this parameter
>>>
>>>
>>>
>> I personally am not comfortable with any syntactic construct where=20
>> function parameter names have non-obvious ramifications. Such as, for=20
>> example adding a function to a class's interface. Also, there's the=20
>> question of how `this` behaves, since it's a keyword.
>>
> I like this syntax *because* it does not differ much from a function=20
> declaration. It emphasizes that member functions are functions with an=20
> implicit this parameter.
>
Yeah, that's kinda the problem: member functions have *other* features=20
besides that. Being members gives them access to privates; if we're=20
allowing out-of-class members, they should be able to access privates too.=
=20
Otherwise, they're *not* member functions, even if you can call them as if=
=20
they were.
In short, member functions are more than just functions that use `this`.
=20
>
>> Does it mean that `foo` gets to use members of `Foo` as though it were a=
=20
>> member function?
>>
> Yes.
>
> Does it get private access too?
>>
> No. Only public (and possibly protected?) access.
>
How can you justify protected and not private? Either it get the same=20
rights as any other member function, or it gets the same rights as a *
non-member* function.
The feature needs to be clear on this: is this simple caller-convenience,=
=20
or are we talking about being able to insert arbitrary code into a finished=
=20
class?
--=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/?hl=3Den.
------=_Part_835_12362102.1364158257179
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<br><br>On Sunday, March 24, 2013 1:12:49 PM UTC-7, stackm...@hotmail.com w=
rote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8e=
x;border-left: 1px #ccc solid;padding-left: 1ex;"><br><br>Am Sonntag, 24. M=
=E4rz 2013 03:06:48 UTC+1 schrieb Nicol Bolas:<blockquote class=3D"gmail_qu=
ote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding=
-left:1ex">On Saturday, March 23, 2013 3:45:30 PM UTC-7, <a>stackm...@hotma=
il.com</a> wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0;margin=
-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex">How about the foll=
owing?<br><div style=3D"background-color:rgb(250,250,250);border-color:rgb(=
187,187,187);border-style:solid;border-width:1px;word-wrap:break-word"><cod=
e><div><span style=3D"color:#008">void</span><span style=3D"color:#000"> fo=
o</span><span style=3D"color:#660">(</span><span style=3D"color:#606">Foo</=
span><span style=3D"color:#660">*</span><span style=3D"color:#000"> </span>=
<span style=3D"color:#008">this</span><span style=3D"color:#660">,</span><s=
pan style=3D"color:#000"> </span><span style=3D"color:#660">...);</span><sp=
an style=3D"color:#000"> </span><span style=3D"color:#800">// explicit this=
parameter</span><span style=3D"color:#000"><br></span></div></code></div><=
br><br></blockquote><div><br>I personally am not comfortable with any synta=
ctic construct where function parameter names have non-obvious ramification=
s. Such as, for example adding a function to a class's interface. Also, the=
re's the question of how `this` behaves, since it's a keyword.</div></block=
quote><div>I like this syntax *because* it does not differ much from a func=
tion declaration. It emphasizes that member functions are functions with an=
implicit this parameter.<br></div></blockquote><div><br>Yeah, that's kinda=
the problem: member functions have <i>other</i> features besides=20
that. Being members gives them access to privates; if we're allowing=20
out-of-class members, they should be able to access privates too.=20
Otherwise, they're <i>not</i> member functions, even if you can call them a=
s if they were.<br><br>In short, member functions are more than just functi=
ons that use `this`.<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> </div><blockquote class=3D"gmail_quote" style=3D"margin:0;=
margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div>Does it=
mean that `foo` gets to use members of `Foo` as though it were a member fu=
nction?</div></blockquote><div> Yes.<br><br></div><blockquote class=3D=
"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc soli=
d;padding-left:1ex"><div>Does it get private access too?<br></div></blockqu=
ote><div>No. Only public (and possibly protected?) access.<br></div></block=
quote><div><br>How can you justify protected and not private? Either it get=
the same rights as any other member function, or it gets the same rights a=
s a <i>non-member</i> function.<br><br>The feature needs to be clear on thi=
s: is this simple caller-convenience, or are we talking about being able to=
insert arbitrary code into a finished 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 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/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
<br />
<br />
------=_Part_835_12362102.1364158257179--
.
Author: stackmachine@hotmail.com
Date: Sun, 24 Mar 2013 17:34:56 -0700 (PDT)
Raw View
------=_Part_2844_21458509.1364171696967
Content-Type: text/plain; charset=ISO-8859-1
>
> How can you justify protected and not private? Either it get the same
> rights as any other member function, or it gets the same rights as a *
> non-member* function.
>
> The feature needs to be clear on this: is this simple caller-convenience,
> or are we talking about being able to insert arbitrary code into a finished
> class?
>
I think of extension methods as the latter. But allowing access to private
(members) allows one to break invariants of the class. You can always
derive a class and get protected access that way, so protected isn't really
protecting anything.
--
---
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/?hl=en.
------=_Part_2844_21458509.1364171696967
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;bor=
der-left: 1px #ccc solid;padding-left: 1ex;"><div>How can you justify prote=
cted and not private? Either it get the same rights as any other member fun=
ction, or it gets the same rights as a <i>non-member</i> function.<br><br>T=
he feature needs to be clear on this: is this simple caller-convenience, or=
are we talking about being able to insert arbitrary code into a finished c=
lass?<br></div></blockquote><div>I think of extension methods as the latter=
.. But allowing access to private (members) allows one to break invariants o=
f the class. You can always derive a class and get protected access that wa=
y, so protected isn't really protecting anything.<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 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/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
<br />
<br />
------=_Part_2844_21458509.1364171696967--
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Sun, 24 Mar 2013 18:40:48 -0700 (PDT)
Raw View
------=_Part_1535_623743.1364175648743
Content-Type: text/plain; charset=ISO-8859-1
On Sunday, March 24, 2013 5:34:56 PM UTC-7, stackm...@hotmail.com wrote:
>
> How can you justify protected and not private? Either it get the same
>> rights as any other member function, or it gets the same rights as a *
>> non-member* function.
>>
>> The feature needs to be clear on this: is this simple caller-convenience,
>> or are we talking about being able to insert arbitrary code into a finished
>> class?
>>
> I think of extension methods as the latter. But allowing access to private
> (members) allows one to break invariants of the class. You can always
> derive a class and get protected access that way, so protected isn't really
> protecting anything.
>
Protected is protecting something: in order to access them, you must
explicitly derive a class, which forces you to use that class in a very
specific way. You have to create a new object type and so forth. You can't
just write a quick function and be done with it. You *have* to impose the
base class interface on your new object type.
So while you can access protected members from outside of a class, you can
only do it under very controlled, easily traceable conditions. What you're
suggesting is that protected means *nothing*, that you can just write any
old global function and it gets to have free access, all because of how a
parameter is named.
Which goes to another point on this syntax. I really don't like the idea of
a parameter name (which, remember, is *optional*) having any effect on a
function declaration or definition. That's pretty unprecedented in C++.
--
---
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/?hl=en.
------=_Part_1535_623743.1364175648743
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<br><br>On Sunday, March 24, 2013 5:34:56 PM UTC-7, stackm...@hotmail.com w=
rote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8e=
x;border-left: 1px #ccc solid;padding-left: 1ex;"><blockquote class=3D"gmai=
l_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;pad=
ding-left:1ex"><div>How can you justify protected and not private? Either i=
t get the same rights as any other member function, or it gets the same rig=
hts as a <i>non-member</i> function.<br><br>The feature needs to be clear o=
n this: is this simple caller-convenience, or are we talking about being ab=
le to insert arbitrary code into a finished class?<br></div></blockquote><d=
iv>I think of extension methods as the latter. But allowing access to priva=
te (members) allows one to break invariants of the class. You can always de=
rive a class and get protected access that way, so protected isn't really p=
rotecting anything.<br></div></blockquote><div><br>Protected is protecting =
something: in order to access them, you must explicitly derive a class, whi=
ch forces you to use that class in a very specific way. You have to create =
a new object type and so forth. You can't just write a quick function and b=
e done with it. You <i>have</i> to impose the base class interface on your =
new object type.<br><br>So while you can access protected members from outs=
ide of a class, you can only do it under very controlled, easily traceable =
conditions. What you're suggesting is that protected means <i>nothing</i>, =
that you can just write any old global function and it gets to have free ac=
cess, all because of how a parameter is named.<br><br>Which goes to another=
point on this syntax. I really don't like the idea of a parameter name (wh=
ich, remember, is <i>optional</i>) having any effect on a function declarat=
ion or definition. That's pretty unprecedented in C++.<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 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/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
<br />
<br />
------=_Part_1535_623743.1364175648743--
.
Author: Olaf van der Spek <olafvdspek@gmail.com>
Date: Mon, 25 Mar 2013 07:37:41 -0700 (PDT)
Raw View
------=_Part_3397_9368999.1364222261773
Content-Type: text/plain; charset=ISO-8859-1
Does this proposal allow me to add explicit operator bool() to (for
example) std::string?
Why can't such operators be non-member functions today?
--
---
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/?hl=en.
------=_Part_3397_9368999.1364222261773
Content-Type: text/html; charset=ISO-8859-1
Does this proposal allow me to add explicit operator bool() to (for example) std::string?<div><br></div><div>Why can't such operators be non-member functions today?</div>
<p></p>
-- <br />
<br />
--- <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 email 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="http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en">http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en</a>.<br />
<br />
<br />
------=_Part_3397_9368999.1364222261773--
.
Author: Beman Dawes <bdawes@acm.org>
Date: Mon, 25 Mar 2013 16:28:03 -0400
Raw View
On Tue, Mar 19, 2013 at 4:43 PM, Ville Voutilainen
<ville.voutilainen@gmail.com> wrote:
> On 19 March 2013 22:34, Fernando Cacciola <fernando.cacciola@gmail.com> wrote:
>> Hmm, OK, I think you are right and in any case it wouldn't be operator .
>> overloading but an alternative syntax.
>
> The unified call syntax also pops up every now and then, but I can't
> easily find a proposal
> for it.
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2004/n1742.pdf by
Francis Glassborow?
--Beman
--
---
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/?hl=en.
.
Author: little3lue <little3lue@gmail.com>
Date: Mon, 25 Mar 2013 16:33:55 -0400
Raw View
--047d7b604fba8f224a04d8c5ba6a
Content-Type: text/plain; charset=ISO-8859-1
Thanks for pointing this out, there is a lot of overlap here.
On Mon, Mar 25, 2013 at 4:28 PM, Beman Dawes <bdawes@acm.org> wrote:
> On Tue, Mar 19, 2013 at 4:43 PM, Ville Voutilainen
> <ville.voutilainen@gmail.com> wrote:
> > On 19 March 2013 22:34, Fernando Cacciola <fernando.cacciola@gmail.com>
> wrote:
> >> Hmm, OK, I think you are right and in any case it wouldn't be operator
> .
> >> overloading but an alternative syntax.
> >
> > The unified call syntax also pops up every now and then, but I can't
> > easily find a proposal
> > for it.
>
> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2004/n1742.pdf by
> Francis Glassborow?
>
> --Beman
>
> --
>
> ---
> 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/17tP4GJbYaI/unsubscribe?hl=en
> .
> 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.
> Visit this group at
> http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.
>
>
>
--
---
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/?hl=en.
--047d7b604fba8f224a04d8c5ba6a
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Thanks for pointing this out, there is a lot of overlap he=
re.</div><div class=3D"gmail_extra"><br><br><div class=3D"gmail_quote">On M=
on, Mar 25, 2013 at 4:28 PM, Beman Dawes <span dir=3D"ltr"><<a href=3D"m=
ailto:bdawes@acm.org" target=3D"_blank">bdawes@acm.org</a>></span> wrote=
:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div class=3D"im">On Tue, Mar 19, 2013 at 4:=
43 PM, Ville Voutilainen<br>
<<a href=3D"mailto:ville.voutilainen@gmail.com">ville.voutilainen@gmail.=
com</a>> wrote:<br>
</div><div class=3D"im">> On 19 March 2013 22:34, Fernando Cacciola <=
<a href=3D"mailto:fernando.cacciola@gmail.com">fernando.cacciola@gmail.com<=
/a>> wrote:<br>
>> Hmm, OK, I think you are right and in any case it wouldn't be =
operator =A0.<br>
>> overloading but an alternative syntax.<br>
><br>
> The unified call syntax also pops up every now and then, but I can'=
;t<br>
> easily find a proposal<br>
> for it.<br>
<br>
</div><a href=3D"http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2004/n1=
742.pdf" target=3D"_blank">http://www.open-std.org/jtc1/sc22/wg21/docs/pape=
rs/2004/n1742.pdf</a> by<br>
Francis Glassborow?<br>
<span class=3D"HOEnZb"><font color=3D"#888888"><br>
--Beman<br>
</font></span><div class=3D"HOEnZb"><div class=3D"h5"><br>
--<br>
<br>
---<br>
You received this message because you are subscribed to a topic in the Goog=
le Groups "ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this topic, visit <a href=3D"https://groups.google.com/=
a/isocpp.org/d/topic/std-proposals/17tP4GJbYaI/unsubscribe?hl=3Den" target=
=3D"_blank">https://groups.google.com/a/isocpp.org/d/topic/std-proposals/17=
tP4GJbYaI/unsubscribe?hl=3Den</a>.<br>
To unsubscribe from this group and all its topics, send an email to <a href=
=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org">std-proposals+unsubscrib=
e@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/?hl=3Den" target=3D"_blank">http://groups.google.com/a/isocpp=
..org/group/std-proposals/?hl=3Den</a>.<br>
<br>
<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" 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/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
<br />
<br />
--047d7b604fba8f224a04d8c5ba6a--
.
Author: mfh1701@gmail.com
Date: Fri, 22 Mar 2013 18:11:52 -0700 (PDT)
Raw View
------=_Part_1311_6135343.1364001112105
Content-Type: text/plain; charset=ISO-8859-1
Personally after countless times where extension methods made C# code less
readable and confusing I'm not convinced that they are a good thing...
--
---
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/?hl=en.
------=_Part_1311_6135343.1364001112105
Content-Type: text/html; charset=ISO-8859-1
<div>Personally after countless times where extension methods made C# code less readable and confusing I'm not convinced that they are a good thing...</div>
<p></p>
-- <br />
<br />
--- <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 email 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="http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en">http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en</a>.<br />
<br />
<br />
------=_Part_1311_6135343.1364001112105--
.
Author: walter1234 <walter2bz@gmail.com>
Date: Wed, 11 Jun 2014 03:37:49 -0700 (PDT)
Raw View
------=_Part_3871_7690765.1402483069495
Content-Type: text/plain; charset=UTF-8
I desperately want this. I guess the fact we don't have it means there are
significant objections, what are they?
Are there enough people in the world that want this to get an experimental
implementation accepted in clang or gcc ? (requiring some nonstandard
switch). Is there anything like that in existence?
The absence of this feature is the main reason I've been looking into the
Rust programming language, where a 'class' is instead split into
struct/trait/impl, so you can have nice chainable .method() calls for
functions without having to mess up your dependancies putting them all in a
class, or creating new types just because you wanted to add new functions.
It could be argued its 'just sugar' but it seems to matter a *lot*. for
example, refactoring code is a lot more awkward when you have to start
changing the calling syntax. (you reduced some dependancies for a helper?
oh but now its not in the class, that helper has to be declared and called
differently, and all the calls have to be changed.).
You can't plan everything first - a language should support design evolving
as you hammer out details through implementation.
Regarding 'access' (public/private) I'd be perfectly happy if extension
methods simply had the same access rights as other free functions. Error
messages can explain whats going on - "extension methods can't access
private members"- so I don't see how it could be confusing.
My suggestion for syntax would simply be to allow declaring a function as
normal, without it needing to have been prototyped inside the class; but I
also like the 'explicit this pointer argument' idea mentioned elsewhere.
void Foo::my_extention_method(args...) { // creates a member-function
for Foo.
this->.. // gets a Foo* this as any other member function would
}
The boost idea of overloading | for chaining might be ingenious but it
would be far better to keep the "bitwise-or" operator for "bitwise or" and
avoid the need for all that boilerplate in the first place.
--
---
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_3871_7690765.1402483069495
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">I desperately want this. I guess the fact we don't have it=
means there are significant objections, what are they?<div><br></div><div>=
Are there enough people in the world that want this to get an experimental =
implementation accepted in clang or gcc ? (requiring some nonstandard switc=
h). Is there anything like that in existence?</div><div><div><br><div>The a=
bsence of this feature is the main reason I've been looking into the Rust p=
rogramming language, where a 'class' is instead split into struct/trait/imp=
l, so you can have nice chainable .method() calls for functions without hav=
ing to mess up your dependancies putting them all in a class, or creating n=
ew types just because you wanted to add new functions.</div><div><br></div>=
<div><br></div><div>It could be argued its 'just sugar' but it seems to mat=
ter a *lot*. for example, refactoring code is a lot more awkward when you h=
ave to start changing the calling syntax. (you reduced some dependancies fo=
r a helper? oh but now its not in the class, that helper has to be declared=
and called differently, and all the calls have to be changed.).</div><div>=
<br></div><div>You can't plan everything first - a language should support =
design evolving as you hammer out details through implementation. </di=
v><div><br></div><div>Regarding 'access' (public/private) I'd be perfectly =
happy if extension methods simply had the same access rights as other free =
functions. Error messages can explain whats going on - "extension methods c=
an't access private members"- so I don't see how it could be confusin=
g. </div><div><br></div><div>My suggestion for syntax would simply be =
to allow declaring a function as normal, without it needing to have been pr=
ototyped inside the class; but I also like the 'explicit this pointer argum=
ent' idea mentioned elsewhere.</div></div></div><div><br></div><div> =
void Foo::my_extention_method(args...) { // creates a member-f=
unction for Foo. </div><div> this->.. // =
gets a Foo* this as any other member function would</div><div> =
}</div><div><br></div><div>The boost idea of overloading | for chaining mi=
ght be ingenious but it would be far better to keep the "bitwise-or" operat=
or for "bitwise or" and avoid the need for all that boilerplate in the firs=
t place.</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_3871_7690765.1402483069495--
.
Author: massimo.tristano@gmail.com
Date: Tue, 24 Jun 2014 01:36:02 -0700 (PDT)
Raw View
------=_Part_1421_21100381.1403598963018
Content-Type: text/plain; charset=UTF-8
I think this feature not only does improve readability
(my_string.ends_with("foo") rather than ends_with(my_string, "foo")) but I
find it absolutely helpful in keeping classes interfaces as minimal and
lean as possible.
With this feature, one would *practically *be able to only write member
functions that interact with private data member within the class
declaration and keep all auxiliary and "helper" functions outside, keeping
the class interface as lean as possible.
An example:
template <typename T>
class vector
{
public:
// size is a getter for a private data member
size_t size() const { return _size; }
private:
size_t _size;
}
// any() and empty() functions only access public data and should be out of
the class.
template <typename T>
bool empty(vector<T>& v)
{
return v.size() == 0;
}
template <typename T>
bool any(vector<T>& v)
{
return v.size() > 0;
}
-Massimo
On Tuesday, 19 March 2013 20:17:04 UTC, Michal Mocny wrote:
>
> I haven't been able to find any proposal on this group for "extension
> methods". What I mean is to allow using the "object-dot-method" sytax to
> call "global-function-with-object-as-first-argument".
>
> i.e.
>
> using std::sort;
> my_vector.sort();
> // or
> my_vector.std::sort();
>
> // especially powerful with chaining, if globals return the target object
> my_vector.sort().tail(10).copy(ostream_iterator...)
> //or
>
> my_vector.sort(std::greater()).head(10).inverted().copy(ostream_iterator...)
>
> etc etc
>
>
> I figure this must have been discussed at some point, given how many
> amazing benefits this would have combined with ranges, concepts, modules
> etc etc. Perhaps there are some serious drawbacks that have already been
> discussed, but I would love to read about them.
>
> 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_1421_21100381.1403598963018
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">I think this feature not only does improve readability (my=
_string.ends_with("foo") rather than ends_with(my_string, "foo")) but I fin=
d it absolutely helpful in keeping classes interfaces as minimal and lean a=
s possible.<div><br></div><div>With this feature, one would <i>practically&=
nbsp;</i>be able to only write member functions that interact with private&=
nbsp;data member within the class declaration and keep all auxiliary a=
nd "helper" functions outside, keeping the class interface as lean as possi=
ble.</div><div><br></div><div>An example:</div><div><font face=3D"courier n=
ew, monospace"><br></font></div><div><font face=3D"courier new, monospace">=
template <typename T></font></div><div><font face=3D"courier new, mon=
ospace">class vector</font></div><div><font face=3D"courier new, monospace"=
>{</font></div><div><font face=3D"courier new, monospace">public:</font></d=
iv><div><font face=3D"courier new, monospace"> // size is a get=
ter for a private data member</font></div><div><font face=3D"courier new, m=
onospace"> size_t size() const { return _size; }</font></div><d=
iv><font face=3D"courier new, monospace"><br></font></div><div><font face=
=3D"courier new, monospace">private:</font></div><div><font face=3D"courier=
new, monospace"> size_t _size;</font></div><div><font face=3D"=
courier new, monospace">}</font></div><div><div><font face=3D"courier new, =
monospace"><br></font></div><div><font face=3D"courier new, monospace">// a=
ny() and empty() functions only access public data and should be out of the=
class.</font></div><div><font face=3D"courier new, monospace">template <=
;typename T></font></div><div><font face=3D"courier new, monospace">bool=
empty(vector<T>& v)</font></div><div><font face=3D"courier new, =
monospace">{</font></div><div><font face=3D"courier new, monospace"> =
return v.size() =3D=3D 0;</font></div><div><font face=3D"courier new,=
monospace">}</font></div></div><div><font face=3D"courier new, monospace">=
<br></font></div><div><div><font face=3D"courier new, monospace">template &=
lt;typename T></font></div><div><font face=3D"courier new, monospace">bo=
ol any(vector<T>& v)</font></div><div><font face=3D"courier new, =
monospace">{</font></div><div><font face=3D"courier new, monospace"> =
return v.size() > 0;</font></div><div><font face=3D"courier new, m=
onospace">}</font></div></div><div><br>-Massimo</div><div><br>On Tuesday, 1=
9 March 2013 20:17:04 UTC, Michal Mocny wrote:<blockquote class=3D"gmail_q=
uote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;pad=
ding-left: 1ex;">I haven't been able to find any proposal on this group for=
"extension methods". What I mean is to allow using the "object-dot-m=
ethod" sytax to call "global-function-with-object-<wbr>as-first-argument".<=
div><br></div><div>i.e.</div><div><br></div><div>using std::sort;</div><div=
>my_vector.sort();</div><div>// or<br></div><div>my_vector.std::sort();</di=
v><div><br></div><div>// especially powerful with chaining, if globals retu=
rn the target object</div><div>my_vector.sort().tail(10).<wbr>copy(ostream_=
iterator...)</div><div>//or</div><div>my_vector.sort(std::greater())<wbr>.h=
ead(10).inverted().copy(<wbr>ostream_iterator...)</div><div><br></div><div>=
etc etc</div><div><br></div><div><br></div><div>I figure this must have bee=
n discussed at some point, given how many amazing benefits this would have =
combined with ranges, concepts, modules etc etc. Perhaps there are so=
me serious drawbacks that have already been discussed, but I would love to =
read about them.</div><div><br>Thanks.</div></blockquote></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_1421_21100381.1403598963018--
.