Topic: Have "extension methods" been proposed for
Author: Lawrence Crowl <crowl@googlers.com>
Date: Wed, 20 Mar 2013 13:56:13 -0700
Raw View
On 3/19/13, Nicol Bolas <jmckesson@gmail.com> wrote:
> On 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".
>
> 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:
> ...
Please also list the benefits. Among them, in my mind, is that it
is easier to follow a sequence of transformations with the infix
notation than the prefix notation.
--
Lawrence Crowl
--
---
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: =?ISO-8859-1?Q?Mikael_Kilpel=E4inen?=
Date: Fri, 22 Mar 2013 10:53:39 +0100
Raw View
This is a multi-part message in MIME format.
--------------010106060601060103050103
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
20.3.2013 0:10, Nicol Bolas kirjoitti:
> 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:
>
> ||
> structT {};
>
> voidFunc(T &t);
> voidFunc(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.
>
Besides these, I would also investigate how it interacts with templates
and sfinae/unevaluated context.
For example:
a.foo();
b.foo( a );
when 'a' is dependent in template context (lookups).
With sfinae, should the free functions be considered if substitution
fails for members?
also..
template<typename T, typename S = decltype( std::declval<T&>().swap(
std::declval<T&>() ) ) >
void func(T);
might have different behaviour now.
Should there then be something similar for static member functions?
Mikael
--
---
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.
--------------010106060601060103050103
Content-Type: text/html; charset=ISO-8859-1
<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
20.3.2013 0:10, Nicol Bolas kirjoitti:
<blockquote
cite="mid:2156cb72-03e4-487e-8bb4-6d4696a3909b@isocpp.org"
type="cite">
<div>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:<br>
<br>
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?<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="prettyprint" style="background-color: rgb(250, 250,
250); border-color: rgb(187, 187, 187); border-style: solid;
border-width: 1px; word-wrap: break-word;"><code
class="prettyprint">
<div class="subprettyprint"><span style="color: #008;"
class="styled-by-prettify">struct</span><span
style="color: #000;" class="styled-by-prettify"> T </span><span
style="color: #660;" class="styled-by-prettify">{};</span><span
style="color: #000;" class="styled-by-prettify"><br>
<br>
</span><span style="color: #008;"
class="styled-by-prettify">void</span><span
style="color: #000;" class="styled-by-prettify"> </span><span
style="color: #606;" class="styled-by-prettify">Func</span><span
style="color: #660;" class="styled-by-prettify">(</span><span
style="color: #000;" class="styled-by-prettify">T </span><span
style="color: #660;" class="styled-by-prettify">&</span><span
style="color: #000;" class="styled-by-prettify">t</span><span
style="color: #660;" class="styled-by-prettify">);</span><span
style="color: #000;" class="styled-by-prettify"><br>
</span><span style="color: #008;"
class="styled-by-prettify">void</span><span
style="color: #000;" class="styled-by-prettify"> </span><span
style="color: #606;" class="styled-by-prettify">Func</span><span
style="color: #660;" class="styled-by-prettify">(</span><span
style="color: #000;" class="styled-by-prettify">T </span><span
style="color: #660;" class="styled-by-prettify">*</span><span
style="color: #000;" class="styled-by-prettify">t</span><span
style="color: #660;" class="styled-by-prettify">);</span><span
style="color: #000;" class="styled-by-prettify"><br>
<br>
T </span><span style="color: #660;"
class="styled-by-prettify">*</span><span style="color:
#000;" class="styled-by-prettify">t </span><span
style="color: #660;" class="styled-by-prettify">=</span><span
style="color: #000;" class="styled-by-prettify"> </span><span
style="color: #660;" class="styled-by-prettify">...</span><span
style="color: #000;" class="styled-by-prettify"><br>
t</span><span style="color: #660;"
class="styled-by-prettify">-></span><span
style="color: #606;" class="styled-by-prettify">Func</span><span
style="color: #660;" class="styled-by-prettify">();</span><span
style="color: #000;" class="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 on these, yes? That is, the
syntax of `s.func()` is exactly equivalent to `func(s)`, once
the feature decides to kick in.<br>
<br>
4: Can the function name include namespace qualifiers? Not
everyone throws `using` qualifiers everywhere.<br>
</div>
<br>
</blockquote>
Besides these, I would also investigate how it interacts with
templates and sfinae/unevaluated context.<br>
<br>
For example:<br>
<br>
a.foo(); <br>
b.foo( a ); <br>
<br>
when 'a' is dependent in template context (lookups).<br>
<br>
With sfinae, should the free functions be considered if substitution
fails for members?<br>
also..<br>
<br>
template<typename T, typename S = decltype(
std::declval<T&>().swap( std::declval<T&>() ) )
><br>
void func(T);<br>
<br>
might have different behaviour now.<br>
<br>
Should there then be something similar for static member functions?<br>
<br>
<br>
Mikael<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
</body>
</html>
<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 />
--------------010106060601060103050103--
.
Author: little3lue <little3lue@gmail.com>
Date: Sun, 24 Mar 2013 21:51:36 -0400
Raw View
--047d7b66f619c2a40a04d8b60ccb
Content-Type: text/plain; charset=ISO-8859-1
I'm writing up a proposal now and will send out for feedback soon.
In the mean time I will clarify: No, I was not proposing access to private
data, nor any new keywords/syntax/opt-in. I used the name "extension
methods" incorrectly, since that term is overloaded given the C# usage. I
merely mean that infix call notation should apply to free functions,
meaning the form foo.bar() is lowered into bar(foo), if and only if
foo.bar() was invalid in the first place (to me, it should be logically
equivalent). Barring any incompatibilities with the current language
rules, it will come down to taste, so I am trying to form an argument for.
My writeup goes into more detail and I would love feedback, especially on
the shortcomings, and hopefully I can send this out tonight.
Thanks!
-Michal
On Sun, Mar 24, 2013 at 9:40 PM, Nicol Bolas <jmckesson@gmail.com> wrote:
>
>
> 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 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.
--047d7b66f619c2a40a04d8b60ccb
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">I'm writing up a proposal now and will send out for fe=
edback soon.<div><br></div><div>In the mean time I will clarify: =A0No, I w=
as not proposing access to private data, nor any new keywords/syntax/opt-in=
.. =A0I used the name "extension methods" incorrectly, since that =
term is overloaded given the C# usage. =A0I merely mean that infix call not=
ation should apply to free functions, meaning the form foo.bar() is lowered=
into bar(foo), if and only if foo.bar() was invalid in the first place (to=
me, it should be logically equivalent). =A0Barring any incompatibilities w=
ith the current language rules, it will come down to taste, so I am trying =
to form an argument for.</div>
<div><br></div><div style>My writeup goes into more detail and I would love=
feedback, especially on the shortcomings, and hopefully I can send this ou=
t tonight.</div><div style><br></div><div style>Thanks!</div><div style>
-Michal</div></div><div class=3D"gmail_extra"><br><br><div class=3D"gmail_q=
uote">On Sun, Mar 24, 2013 at 9:40 PM, Nicol Bolas <span dir=3D"ltr"><<a=
href=3D"mailto:jmckesson@gmail.com" target=3D"_blank">jmckesson@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"><br><br>On Sunday, March 2=
4, 2013 5:34:56 PM UTC-7, <a href=3D"mailto:stackm...@hotmail.com" target=
=3D"_blank">stackm...@hotmail.com</a> wrote:<blockquote class=3D"gmail_quot=
e" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-l=
eft:1ex">
<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;borde=
r-left:1px #ccc solid;padding-left:1ex"><div>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 <i>non-member</i> function.<br>
<br>The feature needs to be clear on this: is this simple caller-convenienc=
e, or are we talking about being able to insert arbitrary code into a finis=
hed class?<br></div></blockquote><div>I think of extension methods as the l=
atter. But allowing access to private (members) allows one to break invaria=
nts of the class. You can always derive a class and get protected access th=
at way, so protected isn't really protecting anything.<br>
</div></blockquote></div><div><br>Protected is protecting something: in ord=
er 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 i=
t. You <i>have</i> to impose the base class interface on your new object ty=
pe.<br>
<br>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 <i>nothing</i>, that you can jus=
t write any old global function and it gets to have free access, all becaus=
e 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 (which, remember, is <i>optional</i>) having any =
effect on a function declaration or definition. That's pretty unprecede=
nted in C++.<br>
</div><div class=3D"HOEnZb"><div class=3D"h5">
<p></p>
-- <br>
=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 />
--047d7b66f619c2a40a04d8b60ccb--
.
Author: little3lue <little3lue@gmail.com>
Date: Sun, 24 Mar 2013 23:04:19 -0400
Raw View
--047d7b343e2ad190c104d8b710e1
Content-Type: text/plain; charset=ISO-8859-1
Please take a look, and comment (in the doc preferred). I'm sure I have
made many mistakes.
https://docs.google.com/document/d/1j8FFGK8VuViNgRcoNIezZMcfhkr4oaXPdZSwFmMnPNs/edit?usp=sharing
Thanks!
On Sun, Mar 24, 2013 at 9:51 PM, little3lue <little3lue@gmail.com> wrote:
> I'm writing up a proposal now and will send out for feedback soon.
>
> In the mean time I will clarify: No, I was not proposing access to
> private data, nor any new keywords/syntax/opt-in. I used the name
> "extension methods" incorrectly, since that term is overloaded given the C#
> usage. I merely mean that infix call notation should apply to free
> functions, meaning the form foo.bar() is lowered into bar(foo), if and only
> if foo.bar() was invalid in the first place (to me, it should be logically
> equivalent). Barring any incompatibilities with the current language
> rules, it will come down to taste, so I am trying to form an argument for.
>
> My writeup goes into more detail and I would love feedback, especially on
> the shortcomings, and hopefully I can send this out tonight.
>
> Thanks!
> -Michal
>
>
> On Sun, Mar 24, 2013 at 9:40 PM, Nicol Bolas <jmckesson@gmail.com> wrote:
>
>>
>>
>> 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 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.
--047d7b343e2ad190c104d8b710e1
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Please take a look, and comment (in the doc preferred). =
=A0I'm sure I have made many mistakes.<div><br></div><div><a href=3D"ht=
tps://docs.google.com/document/d/1j8FFGK8VuViNgRcoNIezZMcfhkr4oaXPdZSwFmMnP=
Ns/edit?usp=3Dsharing">https://docs.google.com/document/d/1j8FFGK8VuViNgRco=
NIezZMcfhkr4oaXPdZSwFmMnPNs/edit?usp=3Dsharing</a><br>
</div><div><br></div><div style>Thanks!</div></div><div class=3D"gmail_extr=
a"><br><br><div class=3D"gmail_quote">On Sun, Mar 24, 2013 at 9:51 PM, litt=
le3lue <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"><div dir=3D"ltr">I'm writing up a propos=
al now and will send out for feedback soon.<div><br></div><div>In the mean =
time I will clarify: =A0No, I was not proposing access to private data, nor=
any new keywords/syntax/opt-in. =A0I used the name "extension methods=
" incorrectly, since that term is overloaded given the C# usage. =A0I =
merely mean that infix call notation should apply to free functions, meanin=
g the form foo.bar() is lowered into bar(foo), if and only if foo.bar() was=
invalid in the first place (to me, it should be logically equivalent). =A0=
Barring any incompatibilities with the current language rules, it will come=
down to taste, so I am trying to form an argument for.</div>
<div><br></div><div>My writeup goes into more detail and I would love feedb=
ack, especially on the shortcomings, and hopefully I can send this out toni=
ght.</div><div><br></div><div>Thanks!</div><div>
-Michal</div></div><div class=3D"HOEnZb"><div class=3D"h5"><div class=3D"gm=
ail_extra"><br><br><div class=3D"gmail_quote">On Sun, Mar 24, 2013 at 9:40 =
PM, Nicol Bolas <span dir=3D"ltr"><<a href=3D"mailto:jmckesson@gmail.com=
" target=3D"_blank">jmckesson@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><br><br>On Sunday, March 24, 2013 5:34:=
56 PM UTC-7, <a href=3D"mailto:stackm...@hotmail.com" target=3D"_blank">sta=
ckm...@hotmail.com</a> wrote:<blockquote class=3D"gmail_quote" style=3D"mar=
gin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex">
<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;borde=
r-left:1px #ccc solid;padding-left:1ex"><div>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 <i>non-member</i> function.<br>
<br>The feature needs to be clear on this: is this simple caller-convenienc=
e, or are we talking about being able to insert arbitrary code into a finis=
hed class?<br></div></blockquote><div>I think of extension methods as the l=
atter. But allowing access to private (members) allows one to break invaria=
nts of the class. You can always derive a class and get protected access th=
at way, so protected isn't really protecting anything.<br>
</div></blockquote></div><div><br>Protected is protecting something: in ord=
er 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 i=
t. You <i>have</i> to impose the base class interface on your new object ty=
pe.<br>
<br>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 <i>nothing</i>, that you can jus=
t write any old global function and it gets to have free access, all becaus=
e 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 (which, remember, is <i>optional</i>) having any =
effect on a function declaration or definition. That's pretty unprecede=
nted in C++.<br>
</div><div><div>
<p></p>
-- <br>
=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>
</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 />
--047d7b343e2ad190c104d8b710e1--
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Sun, 24 Mar 2013 20:42:56 -0700 (PDT)
Raw View
------=_Part_125_1649992.1364182976408
Content-Type: text/plain; charset=ISO-8859-1
On Sunday, March 24, 2013 8:04:19 PM UTC-7, Michal Mocny wrote:
>
> Please take a look, and comment (in the doc preferred). I'm sure I have
> made many mistakes.
>
>
> https://docs.google.com/document/d/1j8FFGK8VuViNgRcoNIezZMcfhkr4oaXPdZSwFmMnPNs/edit?usp=sharing
>
>
Here's a specification problem:
The argument passed to the free function should be the dereferenced object,
> such that (*foo).bar() is the same as foo->bar(), as expected.
>
The problem is that this isn't the case. Those two statements do not have
to be equivalent. operator-> can return a pointer to a completely different
type from the type operator* returns. Obviously this is a *terrible* idea
to do in real code, but it can be done and therefore must be considered. So
how will this work?
--
---
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_125_1649992.1364182976408
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<br><br>On Sunday, March 24, 2013 8:04:19 PM UTC-7, Michal Mocny wrote:<blo=
ckquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-=
left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr">Please take a loo=
k, and comment (in the doc preferred). I'm sure I have made many mist=
akes.<div><br></div><div><a href=3D"https://docs.google.com/document/d/1j8F=
FGK8VuViNgRcoNIezZMcfhkr4oaXPdZSwFmMnPNs/edit?usp=3Dsharing" target=3D"_bla=
nk">https://docs.google.com/<wbr>document/d/<wbr>1j8FFGK8VuViNgRcoNIezZMcfh=
kr4o<wbr>aXPdZSwFmMnPNs/edit?usp=3D<wbr>sharing</a><br>
</div></div><br></blockquote><div> </div><div>Here's a specification p=
roblem:<br><br><div><blockquote style=3D"margin: 0px 0px 0px 0.8ex; border-=
left: 1px solid rgb(204, 204, 204); padding-left: 1ex;" class=3D"gmail_quot=
e"><span style=3D"font-size:15px;font-family:Arial;color:#000000;background=
-color:transparent;font-weight:normal;font-style:normal;font-variant:normal=
;text-decoration:none;vertical-align:baseline;" id=3D"internal-source-marke=
r_0.6378784140393237">The argument passed to the free function should be th=
e dereferenced object, such that </span><span style=3D"font-size:15px;font-=
family:'Courier New';color:#000000;background-color:transparent;font-weight=
:normal;font-style:normal;font-variant:normal;text-decoration:none;vertical=
-align:baseline;">(*foo).bar()</span><span style=3D"font-size:15px;font-fam=
ily:Arial;color:#000000;background-color:transparent;font-weight:normal;fon=
t-style:normal;font-variant:normal;text-decoration:none;vertical-align:base=
line;"> is the same as </span><span style=3D"font-size:15px;font-family:'Co=
urier New';color:#000000;background-color:transparent;font-weight:normal;fo=
nt-style:normal;font-variant:normal;text-decoration:none;vertical-align:bas=
eline;">foo->bar()</span><span style=3D"font-size:15px;font-family:Arial=
;color:#000000;background-color:transparent;font-weight:normal;font-style:n=
ormal;font-variant:normal;text-decoration:none;vertical-align:baseline;">, =
as expected.</span><br></blockquote><br><br>The problem is that this isn't =
the case. Those two statements do not have to be equivalent. operator-> =
can return a pointer to a completely different type from the type operator*=
returns. Obviously this is a <i>terrible</i> idea to do in real code, but =
it can be done and therefore must be considered. So how will this work?<br>=
</div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
<br />
<br />
------=_Part_125_1649992.1364182976408--
.
Author: little3lue <little3lue@gmail.com>
Date: Sun, 24 Mar 2013 23:49:45 -0400
Raw View
--047d7b60525e532c3704d8b7b3de
Content-Type: text/plain; charset=ISO-8859-1
I briefly address concerns about smart pointers in the concerns section
(namely, that that is a concern ;). When I made that statement I meant for
raw pointers.
On Sun, Mar 24, 2013 at 11:42 PM, Nicol Bolas <jmckesson@gmail.com> wrote:
>
>
> On Sunday, March 24, 2013 8:04:19 PM UTC-7, Michal Mocny wrote:
>>
>> Please take a look, and comment (in the doc preferred). I'm sure I have
>> made many mistakes.
>>
>> https://docs.google.com/**document/d/**1j8FFGK8VuViNgRcoNIezZMcfhkr4o**
>> aXPdZSwFmMnPNs/edit?usp=**sharing<https://docs.google.com/document/d/1j8FFGK8VuViNgRcoNIezZMcfhkr4oaXPdZSwFmMnPNs/edit?usp=sharing>
>>
>>
> Here's a specification problem:
>
> The argument passed to the free function should be the dereferenced
>> object, such that (*foo).bar() is the same as foo->bar(), as expected.
>>
>
>
> The problem is that this isn't the case. Those two statements do not have
> to be equivalent. operator-> can return a pointer to a completely different
> type from the type operator* returns. Obviously this is a *terrible* idea
> to do in real code, but it can be done and therefore must be considered. So
> how will this work?
>
> --
>
> ---
> 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.
--047d7b60525e532c3704d8b7b3de
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">I briefly address concerns about smart pointers in the con=
cerns section (namely, that that is a concern ;). =A0When I made that state=
ment I meant for raw pointers.</div><div class=3D"gmail_extra"><br><br><div=
class=3D"gmail_quote">
On Sun, Mar 24, 2013 at 11:42 PM, Nicol Bolas <span dir=3D"ltr"><<a href=
=3D"mailto:jmckesson@gmail.com" target=3D"_blank">jmckesson@gmail.com</a>&g=
t;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0=
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class=3D"im"><br><br>On Sunday, March 24, 2013 8:04:19 PM UTC-7, Micha=
l Mocny wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-le=
ft:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">Plea=
se take a look, and comment (in the doc preferred). =A0I'm sure I have =
made many mistakes.<div>
<br></div><div><a href=3D"https://docs.google.com/document/d/1j8FFGK8VuViNg=
RcoNIezZMcfhkr4oaXPdZSwFmMnPNs/edit?usp=3Dsharing" target=3D"_blank">https:=
//docs.google.com/<u></u>document/d/<u></u>1j8FFGK8VuViNgRcoNIezZMcfhkr4o<u=
></u>aXPdZSwFmMnPNs/edit?usp=3D<u></u>sharing</a><br>
</div></div><br></blockquote><div>=A0</div></div><div>Here's a specific=
ation problem:<br><br><div><blockquote style=3D"margin:0px 0px 0px 0.8ex;bo=
rder-left:1px solid rgb(204,204,204);padding-left:1ex" class=3D"gmail_quote=
">
<span style=3D"vertical-align:baseline;font-variant:normal;font-style:norma=
l;font-size:15px;background-color:transparent;text-decoration:none;font-fam=
ily:Arial;font-weight:normal">The argument passed to the free function shou=
ld be the dereferenced object, such that </span><span style=3D"vertical-ali=
gn:baseline;font-variant:normal;font-style:normal;font-size:15px;background=
-color:transparent;text-decoration:none;font-family:'Courier New';f=
ont-weight:normal">(*foo).bar()</span><span style=3D"vertical-align:baselin=
e;font-variant:normal;font-style:normal;font-size:15px;background-color:tra=
nsparent;text-decoration:none;font-family:Arial;font-weight:normal"> is the=
same as </span><span style=3D"vertical-align:baseline;font-variant:normal;=
font-style:normal;font-size:15px;background-color:transparent;text-decorati=
on:none;font-family:'Courier New';font-weight:normal">foo->bar()=
</span><span style=3D"vertical-align:baseline;font-variant:normal;font-styl=
e:normal;font-size:15px;background-color:transparent;text-decoration:none;f=
ont-family:Arial;font-weight:normal">, as expected.</span><br>
</blockquote><br><br>The problem is that this isn't the case. Those two=
statements do not have to be equivalent. operator-> can return a pointe=
r to a completely different type from the type operator* returns. Obviously=
this is a <i>terrible</i> idea to do in real code, but it can be done and =
therefore must be considered. So how will this work?<br>
</div></div><div class=3D"HOEnZb"><div class=3D"h5">
<p></p>
-- <br>
=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 />
--047d7b60525e532c3704d8b7b3de--
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Mon, 25 Mar 2013 03:41:30 -0700 (PDT)
Raw View
------=_Part_1936_25452417.1364208091001
Content-Type: text/plain; charset=ISO-8859-1
On Sunday, March 24, 2013 8:49:45 PM UTC-7, Michal Mocny wrote:
>
> I briefly address concerns about smart pointers in the concerns section
> (namely, that that is a concern ;). When I made that statement I meant for
> raw pointers.
>
Smart pointers are not the *only* objects that overload operator* and
operator->. And without a resolution to this issue, it's not a complete
proposal. It's just an idea.
Also, I don't see how overloading operator ->* affects the operator* and
operator-> issues.
--
---
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_1936_25452417.1364208091001
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
On Sunday, March 24, 2013 8:49:45 PM UTC-7, Michal Mocny wrote:<blockquote =
class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1p=
x #ccc solid;padding-left: 1ex;"><div dir=3D"ltr">I briefly address concern=
s about smart pointers in the concerns section (namely, that that is a conc=
ern ;). When I made that statement I meant for raw pointers.</div></b=
lockquote><div><br>Smart pointers are not the <i>only</i> objects that over=
load operator* and operator->. And without a resolution to this issue, i=
t's not a complete proposal. It's just an idea.</div><br>Also, I don't see =
how overloading operator ->* affects the operator* and operator-> iss=
ues.<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_1936_25452417.1364208091001--
.
Author: Olaf van der Spek <olafvdspek@gmail.com>
Date: Mon, 25 Mar 2013 07:24:32 -0700 (PDT)
Raw View
------=_Part_1308_21722196.1364221472628
Content-Type: text/plain; charset=ISO-8859-1
Op maandag 25 maart 2013 04:42:56 UTC+1 schreef Nicol Bolas het volgende:
>
>
> On Sunday, March 24, 2013 8:04:19 PM UTC-7, Michal Mocny wrote:
>>
>> Please take a look, and comment (in the doc preferred). I'm sure I have
>> made many mistakes.
>>
>>
>> https://docs.google.com/document/d/1j8FFGK8VuViNgRcoNIezZMcfhkr4oaXPdZSwFmMnPNs/edit?usp=sharing
>>
>>
> Here's a specification problem:
>
> The argument passed to the free function should be the dereferenced
>> object, such that (*foo).bar() is the same as foo->bar(), as expected.
>>
>
>
> The problem is that this isn't the case. Those two statements do not have
> to be equivalent. operator-> can return a pointer to a completely different
> type from the type operator* returns. Obviously this is a *terrible* idea
> to do in real code, but it can be done and therefore must be considered. So
> how will this work?
>
A a;
If A::operator-> returns B* then a->bar() should be mapped to bar(B&); Same
for operator*
What'd happen if a is NULL though?
Should it map to bar(B*) instead?
--
---
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_1308_21722196.1364221472628
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Op maandag 25 maart 2013 04:42:56 UTC+1 schreef Nicol Bolas het volgende:<b=
r><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;b=
order-left: 1px #ccc solid;padding-left: 1ex;"><br><br>On Sunday, March 24,=
2013 8:04:19 PM UTC-7, Michal Mocny wrote:<blockquote class=3D"gmail_quote=
" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-le=
ft:1ex"><div dir=3D"ltr">Please take a look, and comment (in the doc prefer=
red). I'm sure I have made many mistakes.<div><br></div><div><a href=
=3D"https://docs.google.com/document/d/1j8FFGK8VuViNgRcoNIezZMcfhkr4oaXPdZS=
wFmMnPNs/edit?usp=3Dsharing" target=3D"_blank">https://docs.google.com/<wbr=
>document/d/<wbr>1j8FFGK8VuViNgRcoNIezZMcfhkr4o<wbr>aXPdZSwFmMnPNs/edit?usp=
=3D<wbr>sharing</a><br>
</div></div><br></blockquote><div> </div><div>Here's a specification p=
roblem:<br><br><div><blockquote style=3D"margin:0px 0px 0px 0.8ex;border-le=
ft:1px solid rgb(204,204,204);padding-left:1ex" class=3D"gmail_quote"><span=
style=3D"font-size:15px;font-family:Arial;color:#000000;background-color:t=
ransparent;font-weight:normal;font-style:normal;font-variant:normal;text-de=
coration:none;vertical-align:baseline">The argument passed to the free func=
tion should be the dereferenced object, such that </span><span style=3D"fon=
t-size:15px;font-family:'Courier New';color:#000000;background-color:transp=
arent;font-weight:normal;font-style:normal;font-variant:normal;text-decorat=
ion:none;vertical-align:baseline">(*foo).bar()</span><span style=3D"font-si=
ze:15px;font-family:Arial;color:#000000;background-color:transparent;font-w=
eight:normal;font-style:normal;font-variant:normal;text-decoration:none;ver=
tical-align:baseline"> is the same as </span><span style=3D"font-size:15px;=
font-family:'Courier New';color:#000000;background-color:transparent;font-w=
eight:normal;font-style:normal;font-variant:normal;text-decoration:none;ver=
tical-align:baseline">foo->bar()</span><span style=3D"font-size:15px;fon=
t-family:Arial;color:#000000;background-color:transparent;font-weight:norma=
l;font-style:normal;font-variant:normal;text-decoration:none;vertical-align=
:baseline">, as expected.</span><br></blockquote><br><br>The problem is tha=
t this isn't the case. Those two statements do not have to be equivalent. o=
perator-> can return a pointer to a completely different type from the t=
ype operator* returns. Obviously this is a <i>terrible</i> idea to do in re=
al code, but it can be done and therefore must be considered. So how will t=
his work?<br></div></div></blockquote><div><br></div><div>A a;</div><div>If=
A::operator-> returns B* then a->bar() should be mapped to bar(B&=
;); Same for operator*<br></div><div>What'd happen if a is NULL though?&nbs=
p;</div><div>Should it map to bar(B*) instead?</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_1308_21722196.1364221472628--
.
Author: little3lue <little3lue@gmail.com>
Date: Mon, 25 Mar 2013 10:30:48 -0400
Raw View
--047d7b621b14dcc14104d8c0a7d9
Content-Type: text/plain; charset=ISO-8859-1
Thats a great question. I think that since bar(*static_cast<Foo*>(0)) and
static_cast<Foo*>(0)->bar() are both undefined behavior without this
proposa, so should it be undefined if operator-> return nullptr/0.
-Michal
On Mon, Mar 25, 2013 at 10:24 AM, Olaf van der Spek <olafvdspek@gmail.com>wrote:
> Op maandag 25 maart 2013 04:42:56 UTC+1 schreef Nicol Bolas het volgende:
>
>
>>
>> On Sunday, March 24, 2013 8:04:19 PM UTC-7, Michal Mocny wrote:
>>>
>>> Please take a look, and comment (in the doc preferred). I'm sure I have
>>> made many mistakes.
>>>
>>> https://docs.google.com/**document/d/**1j8FFGK8VuViNgRcoNIezZMcfhkr4o**
>>> aXPdZSwFmMnPNs/edit?usp=**sharing<https://docs.google.com/document/d/1j8FFGK8VuViNgRcoNIezZMcfhkr4oaXPdZSwFmMnPNs/edit?usp=sharing>
>>>
>>>
>> Here's a specification problem:
>>
>> The argument passed to the free function should be the dereferenced
>>> object, such that (*foo).bar() is the same as foo->bar(), as expected.
>>>
>>
>>
>> The problem is that this isn't the case. Those two statements do not have
>> to be equivalent. operator-> can return a pointer to a completely different
>> type from the type operator* returns. Obviously this is a *terrible*idea to do in real code, but it can be done and therefore must be
>> considered. So how will this work?
>>
>
> A a;
> If A::operator-> returns B* then a->bar() should be mapped to bar(B&);
> Same for operator*
> What'd happen if a is NULL though?
> Should it map to bar(B*) instead?
>
> --
>
> ---
> 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.
--047d7b621b14dcc14104d8c0a7d9
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Thats a great question. =A0I think that since bar(*static_=
cast<Foo*>(0)) and static_cast<Foo*>(0)->bar() are both unde=
fined behavior without this proposa, so should it be undefined if operator-=
> return nullptr/0.<div>
<br></div><div style>-Michal</div></div><div class=3D"gmail_extra"><br><br>=
<div class=3D"gmail_quote">On Mon, Mar 25, 2013 at 10:24 AM, Olaf van der S=
pek <span dir=3D"ltr"><<a href=3D"mailto:olafvdspek@gmail.com" target=3D=
"_blank">olafvdspek@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">Op maandag 25 maart 2013 04:42:56 UTC+1 schr=
eef Nicol Bolas het volgende:<div class=3D"im"><br><blockquote class=3D"gma=
il_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;pa=
dding-left:1ex">
<br><br>On Sunday, March 24, 2013 8:04:19 PM UTC-7, Michal Mocny wrote:<blo=
ckquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-le=
ft:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">Please take a look, an=
d comment (in the doc preferred). =A0I'm sure I have made many mistakes=
..<div>
<br></div><div><a href=3D"https://docs.google.com/document/d/1j8FFGK8VuViNg=
RcoNIezZMcfhkr4oaXPdZSwFmMnPNs/edit?usp=3Dsharing" target=3D"_blank">https:=
//docs.google.com/<u></u>document/d/<u></u>1j8FFGK8VuViNgRcoNIezZMcfhkr4o<u=
></u>aXPdZSwFmMnPNs/edit?usp=3D<u></u>sharing</a><br>
</div></div><br></blockquote><div>=A0</div><div>Here's a specification =
problem:<br><br><div><blockquote style=3D"margin:0px 0px 0px 0.8ex;border-l=
eft:1px solid rgb(204,204,204);padding-left:1ex" class=3D"gmail_quote"><spa=
n style=3D"vertical-align:baseline;font-variant:normal;font-style:normal;fo=
nt-size:15px;background-color:transparent;text-decoration:none;font-family:=
Arial;font-weight:normal">The argument passed to the free function should b=
e the dereferenced object, such that </span><span style=3D"vertical-align:b=
aseline;font-variant:normal;font-style:normal;font-size:15px;background-col=
or:transparent;text-decoration:none;font-family:'Courier New';font-=
weight:normal">(*foo).bar()</span><span style=3D"vertical-align:baseline;fo=
nt-variant:normal;font-style:normal;font-size:15px;background-color:transpa=
rent;text-decoration:none;font-family:Arial;font-weight:normal"> is the sam=
e as </span><span style=3D"vertical-align:baseline;font-variant:normal;font=
-style:normal;font-size:15px;background-color:transparent;text-decoration:n=
one;font-family:'Courier New';font-weight:normal">foo->bar()</sp=
an><span style=3D"vertical-align:baseline;font-variant:normal;font-style:no=
rmal;font-size:15px;background-color:transparent;text-decoration:none;font-=
family:Arial;font-weight:normal">, as expected.</span><br>
</blockquote><br><br>The problem is that this isn't the case. Those two=
statements do not have to be equivalent. operator-> can return a pointe=
r to a completely different type from the type operator* returns. Obviously=
this is a <i>terrible</i> idea to do in real code, but it can be done and =
therefore must be considered. So how will this work?<br>
</div></div></blockquote><div><br></div></div><div>A a;</div><div>If A::ope=
rator-> returns B* then a->bar() should be mapped to bar(B&); Sam=
e for operator*<br></div><div>What'd happen if a is NULL though?=A0</di=
v>
<div>Should it map to bar(B*) instead?</div><div class=3D"HOEnZb"><div clas=
s=3D"h5">
<p></p>
-- <br>
=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 />
--047d7b621b14dcc14104d8c0a7d9--
.
Author: little3lue <little3lue@gmail.com>
Date: Mon, 25 Mar 2013 10:46:34 -0400
Raw View
--047d7b66f619479c7e04d8c0e0ee
Content-Type: text/plain; charset=ISO-8859-1
If it were valid to write a free function that accepted a std::string as
first parameter, then it might perhaps have been possible, but I don't
think it is, sorry.
-Michal
On Mon, Mar 25, 2013 at 10:37 AM, Olaf van der Spek <olafvdspek@gmail.com>wrote:
> 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 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.
--047d7b66f619479c7e04d8c0e0ee
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">If it were valid to write a free function that accepted a =
std::string as first parameter, then it might perhaps have been possible, b=
ut I don't think it is, sorry.<div><br></div><div>-Michal</div></div><d=
iv class=3D"gmail_extra">
<br><br><div class=3D"gmail_quote">On Mon, Mar 25, 2013 at 10:37 AM, Olaf v=
an der Spek <span dir=3D"ltr"><<a href=3D"mailto:olafvdspek@gmail.com" t=
arget=3D"_blank">olafvdspek@gmail.com</a>></span> wrote:<br><blockquote =
class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid=
;padding-left:1ex">
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-membe=
r functions today?</div><div class=3D"HOEnZb"><div class=3D"h5">
<p></p>
-- <br>
=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 />
--047d7b66f619479c7e04d8c0e0ee--
.
Author: =?ISO-8859-1?Q?Daniel_Kr=FCgler?= <daniel.kruegler@gmail.com>
Date: Mon, 25 Mar 2013 15:57:07 +0100
Raw View
2013/3/25 Olaf van der Spek <olafvdspek@gmail.com>:
> 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?
I don't think that any language extension will allow you to modify the
Standard Library. Even if you ignore the general requirements from
Clause 17 in that regard, you would easily produce undefined behaviour
because of possible ODR violations. Consider some third-party tool
that contains some sfinae-code that controls template instantiations
based on std::is_constructible<bool, T>: Presumably this library code
does not "see" your addition of explicit operator bool, so will lead
to different template definitions for TUs that have your definition
added and for those that have not.
- 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: Olaf van der Spek <olafvdspek@gmail.com>
Date: Mon, 25 Mar 2013 16:55:20 +0100
Raw View
On Mon, Mar 25, 2013 at 3:57 PM, Daniel Kr=FCgler
<daniel.kruegler@gmail.com> wrote:
> 2013/3/25 Olaf van der Spek <olafvdspek@gmail.com>:
>> Does this proposal allow me to add explicit operator bool() to (for exam=
ple)
>> std::string?
>>
>> Why can't such operators be non-member functions today?
>
> I don't think that any language extension will allow you to modify the
> Standard Library. Even if you ignore the general requirements from
> Clause 17 in that regard, you would easily produce undefined behaviour
> because of possible ODR violations. Consider some third-party tool
> that contains some sfinae-code that controls template instantiations
> based on std::is_constructible<bool, T>: Presumably this library code
> does not "see" your addition of explicit operator bool, so will lead
> to different template definitions for TUs that have your definition
> added and for those that have not.
That ODR problem isn't specific to such class extensions, is it?
ODR violations are always a potential issue.
--=20
Olaf
--=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.
.
Author: little3lue <little3lue@gmail.com>
Date: Mon, 25 Mar 2013 11:57:14 -0400
Raw View
--047d7b343e2afc66ac04d8c1dc8d
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Your "operator bool(std::string const&)" would have lived outside the std
namespace, right? In that case, I think I agree with you. But I should
discuss ODR in the doc as well, thanks for reminder.
On Mon, Mar 25, 2013 at 11:55 AM, Olaf van der Spek <olafvdspek@gmail.com>w=
rote:
> On Mon, Mar 25, 2013 at 3:57 PM, Daniel Kr=FCgler
> <daniel.kruegler@gmail.com> wrote:
> > 2013/3/25 Olaf van der Spek <olafvdspek@gmail.com>:
> >> 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?
> >
> > I don't think that any language extension will allow you to modify the
> > Standard Library. Even if you ignore the general requirements from
> > Clause 17 in that regard, you would easily produce undefined behaviour
> > because of possible ODR violations. Consider some third-party tool
> > that contains some sfinae-code that controls template instantiations
> > based on std::is_constructible<bool, T>: Presumably this library code
> > does not "see" your addition of explicit operator bool, so will lead
> > to different template definitions for TUs that have your definition
> > added and for those that have not.
>
> That ODR problem isn't specific to such class extensions, is it?
> ODR violations are always a potential issue.
>
> --
> Olaf
>
> --
>
> ---
> 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.
--047d7b343e2afc66ac04d8c1dc8d
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Your "operator bool(std::string const&)" wou=
ld have lived outside the std namespace, right? =A0In that case, I think I =
agree with you. =A0But I should discuss ODR in the doc as well, thanks for =
reminder.</div>
<div class=3D"gmail_extra"><br><br><div class=3D"gmail_quote">On Mon, Mar 2=
5, 2013 at 11:55 AM, Olaf van der Spek <span dir=3D"ltr"><<a href=3D"mai=
lto:olafvdspek@gmail.com" target=3D"_blank">olafvdspek@gmail.com</a>></s=
pan> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div class=3D"im">On Mon, Mar 25, 2013 at 3:=
57 PM, Daniel Kr=FCgler<br>
<<a href=3D"mailto:daniel.kruegler@gmail.com">daniel.kruegler@gmail.com<=
/a>> wrote:<br>
> 2013/3/25 Olaf van der Spek <<a href=3D"mailto:olafvdspek@gmail.com=
">olafvdspek@gmail.com</a>>:<br>
>> Does this proposal allow me to add explicit operator bool() to (fo=
r example)<br>
>> std::string?<br>
>><br>
>> Why can't such operators be non-member functions today?<br>
><br>
> I don't think that any language extension will allow you to modify=
the<br>
> Standard Library. Even if you ignore the general requirements from<br>
> Clause 17 in that regard, you would easily produce undefined behaviour=
<br>
> because of possible ODR violations. Consider some third-party tool<br>
> that contains some sfinae-code that controls template instantiations<b=
r>
> based on std::is_constructible<bool, T>: Presumably this library=
code<br>
> does not "see" your addition of explicit operator bool, so w=
ill lead<br>
> to different template definitions for TUs that have your definition<br=
>
> added and for those that have not.<br>
<br>
</div>That ODR problem isn't specific to such class extensions, is it?<=
br>
ODR violations are always a potential issue.<br>
<span class=3D"HOEnZb"><font color=3D"#888888"><br>
--<br>
Olaf<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 />
--047d7b343e2afc66ac04d8c1dc8d--
.
Author: Tony V E <tvaneerd@gmail.com>
Date: Mon, 25 Mar 2013 16:56:28 -0400
Raw View
On Sun, Mar 24, 2013 at 11:04 PM, little3lue <little3lue@gmail.com> wrote:
> Please take a look, and comment (in the doc preferred). I'm sure I have
> made many mistakes.
>
> https://docs.google.com/document/d/1j8FFGK8VuViNgRcoNIezZMcfhkr4oaXPdZSwFmMnPNs/edit?usp=sharing
>
> Thanks!
>
>
Given crazy uses of SFINAE, are you sure "This proposal would not
change the behaviour of any existing application in any way."
ie I can write a template that checks if foo.bar() is valid, and do
something different if not. Wouldn't this extension change the result
of that template?
(Note, my opinion would be that it *should* change the behaviour.
That may break existing code in a few small places, but would be the
"right" thing to do.)
Tony
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.
.
Author: =?ISO-8859-1?Q?Mikael_Kilpel=E4inen?=
Date: Mon, 25 Mar 2013 22:02:27 +0100
Raw View
25.3.2013 21:56, Tony V E kirjoitti:
> On Sun, Mar 24, 2013 at 11:04 PM, little3lue<little3lue@gmail.com> wrote:
>> Please take a look, and comment (in the doc preferred). I'm sure I have
>> made many mistakes.
>>
>> https://docs.google.com/document/d/1j8FFGK8VuViNgRcoNIezZMcfhkr4oaXPdZSwFmMnPNs/edit?usp=sharing
>>
>> Thanks!
>>
>>
> Given crazy uses of SFINAE, are you sure "This proposal would not
> change the behaviour of any existing application in any way."
>
> ie I can write a template that checks if foo.bar() is valid, and do
> something different if not. Wouldn't this extension change the result
> of that template?
Certainly, I already showed such example earlier on.
> (Note, my opinion would be that it *should* change the behaviour.
> That may break existing code in a few small places, but would be the
> "right" thing to do.)
>
Maybe.. Also I would consider the template context for the lookups, not
from users perspective but the compilers.
Mikael
--
---
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: Olaf van der Spek <olafvdspek@gmail.com>
Date: Mon, 25 Mar 2013 22:35:49 +0100
Raw View
On Mon, Mar 25, 2013 at 4:57 PM, little3lue <little3lue@gmail.com> wrote:
> Your "operator bool(std::string const&)" would have lived outside the std
> namespace, right? In that case, I think I agree with you.
Don't know. It should extend std::string, I don't mind where it lives.
I'd like to avoid requiring it to be in the global namespace.
--
---
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: Lawrence Crowl <crowl@googlers.com>
Date: Tue, 26 Mar 2013 17:52:54 -0700
Raw View
On 3/22/13, mfh1701@gmail.com <mfh1701@gmail.com> wrote:
> Personally after countless times where extension methods made C#
> code less readable and confusing I'm not convinced that they are
> a good thing...
Concrete examples would help.
--
Lawrence Crowl
--
---
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: David Krauss <potswa@gmail.com>
Date: Wed, 11 Jun 2014 19:02:27 +0800
Raw View
On 2014-06-11, at 6:37 PM, walter1234 <walter2bz@gmail.com> wrote:
> It could be argued its 'just sugar' but it seems to matter a *lot*. for e=
xample, refactoring code is a lot more awkward when you have to start chang=
ing 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 differ=
ently, and all the calls have to be changed.).
The problem is that it's not just sugar. Sugar is when a shortcut is introd=
uced for something that's already possible.
C++ classes are "closed" and extension methods somehow need to reconcile wi=
th vtable generation, template instantiation, etc. Also, C++ helps large pr=
ojects contain components into their own sandboxes. Class extensions must s=
omehow be contained in the user's namespace (different from the class names=
pace), yet with sensible rules for being found by lookup.
> You can't plan everything first - a language should support design evolvi=
ng as you hammer out details through implementation.=20
This is almost a separate issue. Proper interfaces shouldn't declare privat=
e members, either.
> Regarding 'access' (public/private) I'd be perfectly happy if extension m=
ethods simply had the same access rights as other free functions. Error mes=
sages can explain whats going on - "extension methods can't access private =
members"- so I don't see how it could be confusing.=20
This is a given.
> 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.
It sounds like you've already started researching existing literature :)
Now is a good time to be submitting proposals, because we're early in the d=
evelopment cycle targeting the 2017 standard edition.
> void Foo::my_extention_method(args...) { // creates a member-functio=
n for Foo.=20
> this->.. // gets a Foo* this as any other member function would
> }
Hmm, if it looks too much like a regular member declaration, then it's too =
easy to accidentally define a member which does not match the one declared =
by the header. Proper compiler diagnostics may be demoted to link errors.
Anyway, submitting syntax alternatives into a popularity contest is the eas=
y part. The devil is in the details.
The nice thing about languages like Rust is simplicity, and there's nothing=
wrong with it as the right tool for the job. C++ shines when you have boat=
loads of code that need to run as fast as possible.
--=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/.
.
Author: Ville Voutilainen <ville.voutilainen@gmail.com>
Date: Wed, 11 Jun 2014 15:04:15 +0300
Raw View
On 11 June 2014 14:02, David Krauss <potswa@gmail.com> wrote:
>> 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.
>
> It sounds like you've already started researching existing literature :)
>
> Now is a good time to be submitting proposals, because we're early in the development cycle targeting the 2017 standard edition.
For what it's worth, it was briefly mentioned in Kona two years ago
that some people
desire f(x) being able to call x.f(), but extension methods as such
were not necessarily
part of that particular idea, although they have been mentioned in connection.
As David indicates, C++17 work starts next monday, so now indeed is a good time
to be submitting proposals for new extensions.
What I remember from brief discussions about such facilities, I think
there are people
who prefer classes being closed, and not having to guess where to find
the function
in the expression x.f(). Providing a good solution with good
motivation and taking
that (and the aspects David enumerated) into account is likely needed
for a proposal
to have a chance of succeeding. I would also expect such a proposal to estimate
the standardese changes needed, the implementation complexity, and compatibility
with existing code.
--
---
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/.
.
Author: walter1234 <walter2bz@gmail.com>
Date: Wed, 11 Jun 2014 15:15:51 -0700 (PDT)
Raw View
------=_Part_429_362914.1402524952771
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
>>The problem is that it=E2=80=99s not just sugar. Sugar is when a shortcut=
is=20
introduced for something that=E2=80=99s already possible.=20
>>C++ classes are =E2=80=9Cclosed=E2=80=9D and extension methods somehow ne=
ed to reconcile=20
with vtable generation,
My suggestion is that this is purely sugar for free functions. A free=20
function who's calling style is consistent when you move it in or out of=20
the class (when refactoring), and giving the same a.foo().bar().baz()=20
'chaining' syntax.
I am not suggesting this should affect vtables at all - of course, the=20
vtable really is part of the class declaration, that I understand.
In my typical use cases vtables are avoided for performance reasons.
For access rights, I suggest that 'extension methods' should be the same as=
=20
free-functions. Error messages can explain what,and why, that is, avoiding=
=20
confusion.
>>need to reconcile with ...., template instantiation,=20
Templates work fine for foo(a,b) free functions - which may select=20
implementations based on the type of any parameter - so I don't see any=20
fundamental reason why that can't work for a.foo(b) aswell
Its purely cultural - perception of a 'method' vs a 'function' that is=20
holding us back here - and in my case, creating a demand for a whole new=20
language , when it really is just one or two small modifications that would=
=20
keep C++ working fine for me. Obviously my thinking isn't *that* far out,=
=20
because many more recent language - Rust, Go, and now Swift - all allow=20
extending 'methods' outside of the class, for static dispatch. (I really=
=20
hope C++ eventually copies their ability to roll a fat-pointer vtable -=20
interface aswell - in the case of c++ proposal it would be a=20
'concept-object' i guess to match a Rust 'trait object', but that's not so=
=20
critical for me)
>>This is almost a separate issue. Proper interfaces shouldn=E2=80=99t decl=
are=20
private members, either.=20
Its very closely related:
Moving from C to C++ my big bug-bear was how much more you are forced to=20
put in headers. In C the header is very much an interface in a low level=20
sense.
In C, you can forward declare a type , and put 'interface function'=20
prototypes in the header, which take opaque pointers. The implementation=20
details (the struct members, and helper functions) don't need to be in the=
=20
header.
In C++, if you want method-call syntax for methods (a very addictive=20
sugar) that compile the same as functions, you must declare the whole class=
=20
*in the header*, including its' private members.
If you had 'extension methods' you could go back to what C allows, by just=
=20
forward declaring the class & its' public methods, a more restricted=20
interface in the header, and still use 'method call syntax' - no extra=20
'PIMPL' boiler-plate or pointers required.
of course if you're using vtables you can use abstract interfaces, but my=
=20
use cases usually avoid them.=20
of course I realise sometimes you need the whole class for inlining, but=20
not *always*. These are details which can be dynamic as a project=20
progresses, and it might be possible for build systems to defer inlining?=
=20
You might start out with an interface that doesn't need inlining, and=20
change it later. or vica versa.
>>It sounds like you=E2=80=99ve already started researching existing litera=
ture :)=20
just this thread recently, and I've asked around before.
yes - I've been tortured by this issue ever since I first started using C++=
=20
15+ years ago - I believe it's caused many problems in the workplace-=20
fundamentally functions are easier to decouple and re-use (IMO) - and its'=
=20
driven me 2+ years ago to start looking for a C++ alternative.
Rust of course addresses this and many other "if only C++ could..."=20
issues, its been refreshing to learn, but I'd be happy to stick with C++=20
just with this issue fixed... and one huge downside to Rust is losing=20
mature IDE tools.
>>Hmm, if it looks too much like a regular member declaration, then it=E2=
=80=99s=20
too easy to accidentally define a member which does not match the one=20
declared by the header. Proper compiler diagnostics may be demoted to link=
=20
errors.
Well that would be an argument in favour of the 'explicit this pointer'. I=
=20
realise C++ has an issue that its' hard to add keywords. In 'rust' and=20
'swift' they have the freedom to do this (impl{}.. extension{ }), without=
=20
legacy code.=20
>> then it=E2=80=99s too easy to accidentally define a member which does no=
t match=20
the one declared by the header.=20
I should mention that *NOT* needing to put every function in the header is=
=20
also a goal. I would like the ability to declare one thing in one place,=20
restrict what needs to appear in headers. also small helpers (a really big=
=20
use for this) would probably be inlined, and may be defined purely in=20
headers.
The reason I suggest this simple syntax is that it might be the easiest to=
=20
try out in a compiler implementation right now - if it was a nonstandard=20
extension ,enabled with a switch or pragma, that would be nice ... if the=
=20
world can get whole new languages to deal with issues like this ....perhaps=
=20
a fork of C++ would be possible.=20
>>The nice thing about languages like Rust is simplicity, and there=E2=80=
=99s=20
nothing wrong with it as the right tool for the job. C++ shines when you=20
>>have boatloads of code that need to run as fast as possible.=20
C++ remains the right mainstream tool for my interest. Rust is under=20
consideration because its close enough to C++'s philosophy of 'you don't=20
pay for what you don't use'- no runtime needed, same precise control over=
=20
memory.=20
There's a lot to like about Rust (especially the safety aspects) but=20
there,of course I run into other issues: the generic system isn't yet as=20
capable as C++, so there's things i'm used to being able to do e.g. for=20
vector maths with custom types that it can't quite match; also I find you=
=20
pay for the simplifications in its language engine by needing more work=20
naming: a function *must* have an associated trait, there are no conversion=
=20
operators (instead they use naming conventions for functions) , and without=
=20
overloading, again you find yourself making many named variations of the=20
same functions. More to search through in documentation whereas you can use=
=20
overloading to say things with types, and the compiler searches for you..=
=20
and we already have the IDE's to deal with 'jump-to-definition' ambiguities=
..
On Wednesday, 11 June 2014 12:02:40 UTC+1, David Krauss wrote:
>
>
> On 2014=E2=80=9306=E2=80=9311, at 6:37 PM, walter1234 <walt...@gmail.com =
<javascript:>>=20
> wrote:=20
>
> > It could be argued its 'just sugar' but it seems to matter a *lot*. for=
=20
> example, refactoring code is a lot more awkward when you have to start=20
> changing the calling syntax. (you reduced some dependancies for a helper?=
=20
> oh but now its not in the class, that helper has to be declared and calle=
d=20
> differently, and all the calls have to be changed.).=20
>
> The problem is that it=E2=80=99s not just sugar. Sugar is when a shortcut=
is=20
> introduced for something that=E2=80=99s already possible.=20
>
> C++ classes are =E2=80=9Cclosed=E2=80=9D and extension methods somehow ne=
ed to reconcile=20
> with vtable generation, template instantiation, etc. Also, C++ helps larg=
e=20
> projects contain components into their own sandboxes. Class extensions mu=
st=20
> somehow be contained in the user=E2=80=99s namespace (different from the =
class=20
> namespace), yet with sensible rules for being found by lookup.=20
>
> > You can't plan everything first - a language should support design=20
> evolving as you hammer out details through implementation.=20
>
> This is almost a separate issue. Proper interfaces shouldn=E2=80=99t decl=
are=20
> private members, either.=20
>
> > Regarding 'access' (public/private) I'd be perfectly happy if extension=
=20
> methods simply had the same access rights as other free functions. Error=
=20
> messages can explain whats going on - "extension methods can't access=20
> private members"- so I don't see how it could be confusing.=20
>
> This is a given.=20
>
> > My suggestion for syntax would simply be to allow declaring a function=
=20
> as normal, without it needing to have been prototyped inside the class; b=
ut=20
> I also like the 'explicit this pointer argument' idea mentioned elsewhere=
..=20
>
> It sounds like you=E2=80=99ve already started researching existing litera=
ture :)=20
>
> Now is a good time to be submitting proposals, because we=E2=80=99re earl=
y in the=20
> development cycle targeting the 2017 standard edition.=20
>
> > void Foo::my_extention_method(args...) { // creates a=20
> member-function for Foo.=20
> > this->.. // gets a Foo* this as any other member function would=
=20
> > }=20
>
> Hmm, if it looks too much like a regular member declaration, then it=E2=
=80=99s too=20
> easy to accidentally define a member which does not match the one declare=
d=20
> by the header. Proper compiler diagnostics may be demoted to link errors.=
=20
>
> >> Anyway, submitting syntax alternatives into a popularity contest is th=
e=20
> easy part. The devil is in the details.=20
>
=20
>
> The nice thing about languages like Rust is simplicity, and there=E2=80=
=99s=20
> nothing wrong with it as the right tool for the job. C++ shines when you=
=20
> have boatloads of code that need to run as fast as possible.=20
>
> =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/.
------=_Part_429_362914.1402524952771
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br>>>The problem is that it=E2=80=99s not just suga=
r. Sugar is when a shortcut is introduced for something that=E2=80=99s alre=
ady possible. <br>>>C++ classes are =E2=80=9Cclosed=E2=80=9D and=
extension methods somehow need to reconcile with vtable generation,<div><b=
r></div><div>My suggestion is that this is purely sugar for free functions.=
A free function who's calling style is consistent when you move it in or o=
ut of the class (when refactoring), and giving the same a.foo().bar().baz()=
'chaining' syntax.</div><div><br></div><div>I am not suggesting this shoul=
d affect vtables at all - of course, the vtable really is part of the class=
declaration, that I understand.</div><div>In my typical use cases vtables =
are avoided for performance reasons.</div><div><br></div><div>For access ri=
ghts, I suggest that 'extension methods' should be the same as free-functio=
ns. Error messages can explain what,and why, that is, avoiding confusion.</=
div><div><br></div><div>>>need to reconcile with ...., template insta=
ntiation, </div><div><br></div><div>Templates work fine for foo(a,b) f=
ree functions - which may select implementations based on the type of any p=
arameter - so I don't see any fundamental reason why that can't work for a.=
foo(b) aswell</div><div><br></div><div>Its purely cultural - perception of =
a 'method' vs a 'function' that is holding us back here - and in my case, c=
reating a demand for a whole new language , when it really is just one or t=
wo small modifications that would keep C++ working fine for me. Obviously m=
y thinking isn't *that* far out, because many more recent language - Rust, =
Go, and now Swift - all allow extending 'methods' outside of the class, &nb=
sp;for static dispatch. (I really hope C++ eventually copies their ability =
to roll a fat-pointer vtable - interface aswell - in the case of c++ propos=
al it would be a 'concept-object' i guess to match a Rust 'trait object', b=
ut that's not so critical for me)</div><div><br></div><div>>>This is =
almost a separate issue. Proper interfaces shouldn=E2=80=99t declare privat=
e members, either. </div><div><br></div><div>Its very closely related:=
</div><div>Moving from C to C++ my big bug-bear was how much more you are f=
orced to put in headers. In C the header is very much an interface in a low=
level sense.</div><div>In C, you can forward declare a type , and put 'int=
erface function' prototypes in the header, which take opaque pointers. The =
implementation details (the struct members, and helper functions) don't nee=
d to be in the header.</div><div>In C++, if you want method-call syntax &nb=
sp;for methods (a very addictive sugar) that compile the same as functions,=
you must declare the whole class *in the header*, including its' private m=
embers.</div><div><br></div><div>If you had 'extension methods' you could g=
o back to what C allows, by just forward declaring the class & its' pub=
lic methods, a more restricted interface in the header, and still use 'meth=
od call syntax' - no extra 'PIMPL' boiler-plate or pointers required.</div>=
<div><br></div><div>of course if you're using vtables you can use abstract =
interfaces, but my use cases usually avoid them. </div><div><br></div>=
<div>of course I realise sometimes you need the whole class for inlining, b=
ut not *always*. These are details which can be dynamic as a project progre=
sses, and it might be possible for build systems to defer inlining? You mig=
ht start out with an interface that doesn't need inlining, and change it la=
ter. or vica versa.</div><div><br></div><div>>>It sounds like you=E2=
=80=99ve already started researching existing literature :) </div><div=
><br></div><div>just this thread recently, and I've asked around before.</d=
iv><div>yes - I've been tortured by this issue ever since I first started u=
sing C++ 15+ years ago - I believe it's caused many problems in the workpla=
ce- fundamentally functions are easier to decouple and re-use (IMO) - and i=
ts' driven me 2+ years ago to start looking for a C++ alternative.</div><di=
v><br></div><div>Rust of course addresses this and many other "if onl=
y C++ could..." issues, its been refreshing to learn, but I'd be happy to s=
tick with C++ just with this issue fixed... and one huge downside to Rust i=
s losing mature IDE tools.</div><div><br></div><div><div>>>Hmm, if it=
looks too much like a regular member declaration, then it=E2=80=99s too ea=
sy to accidentally define a member which does not match the one declared by=
the header. Proper compiler diagnostics may be demoted to link errors.</di=
v></div><div><br></div><div>Well that would be an argument in favour of the=
'explicit this pointer'. I realise C++ has an issue that its' hard to add =
keywords. In 'rust' and 'swift' they have the freedom to do this (imp=
l{}.. extension{ }), without legacy code. </div><div><br></div><div>&g=
t;> then it=E2=80=99s too easy to accidentally define a member which doe=
s not match the one declared by the header. <br></div><div><br></div><=
div>I should mention that *NOT* needing to put every function in the header=
is also a goal. I would like the ability to declare one thing in one place=
, restrict what needs to appear in headers. also small helpers (a really bi=
g use for this) would probably be inlined, and may be defined purely in hea=
ders.</div><div><br></div><div>The reason I suggest this simple syntax is t=
hat it might be the easiest to try out in a compiler implementation right n=
ow - if it was a nonstandard extension ,enabled with a switch or pragma, th=
at would be nice ... if the world can get whole new languages to deal with =
issues like this ....perhaps a fork of C++ would be possible. </div><d=
iv><br></div><div>>>The nice thing about languages like Rust is simpl=
icity, and there=E2=80=99s nothing wrong with it as the right tool for the =
job. C++ shines when you >>have boatloads of code that need to run as=
fast as possible. <br><br>C++ remains the right mainstream tool for m=
y interest. Rust is under consideration because its close enough to C++'s p=
hilosophy of 'you don't pay for what you don't use'- no runtime neede=
d, same precise control over memory. </div><div><br></div><div>There's=
a lot to like about Rust (especially the safety aspects) but there,of cour=
se I run into other issues: the generic system isn't yet as capable as C++,=
so there's things i'm used to being able to do e.g. for vector maths with =
custom types that it can't quite match; also I find you pay for the simplif=
ications in its language engine by needing more work naming: a function *mu=
st* have an associated trait, there are no conversion operators (instead th=
ey use naming conventions for functions) , and without overloading, again y=
ou find yourself making many named variations of the same functions. More t=
o search through in documentation whereas you can use overloading to say th=
ings with types, and the compiler searches for you.. and we already have th=
e IDE's to deal with 'jump-to-definition' ambiguities.</div><div><br></div>=
<div><br></div><div><br></div><div><br>On Wednesday, 11 June 2014 12:02:40 =
UTC+1, David Krauss wrote:<blockquote class=3D"gmail_quote" style=3D"margi=
n: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">
<br>On 2014=E2=80=9306=E2=80=9311, at 6:37 PM, walter1234 <<a href=3D"ja=
vascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"JIkXkTiM6J4J" onmouse=
down=3D"this.href=3D'javascript:';return true;" onclick=3D"this.href=3D'jav=
ascript:';return true;">walt...@gmail.com</a>> wrote:
<br>
<br>> 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 star=
t 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.).
<br>
<br>The problem is that it=E2=80=99s not just sugar. Sugar is when a shortc=
ut is introduced for something that=E2=80=99s already possible.
<br>
<br>C++ classes are =E2=80=9Cclosed=E2=80=9D and extension methods somehow =
need to reconcile with vtable generation, template instantiation, etc. Also=
, C++ helps large projects contain components into their own sandboxes. Cla=
ss extensions must somehow be contained in the user=E2=80=99s namespace (di=
fferent from the class namespace), yet with sensible rules for being found =
by lookup.
<br>
<br>> You can't plan everything first - a language should support design=
evolving as you hammer out details through implementation.=20
<br>
<br>This is almost a separate issue. Proper interfaces shouldn=E2=80=99t de=
clare private members, either.
<br>
<br>> Regarding 'access' (public/private) I'd be perfectly happy if exte=
nsion methods simply had the same access rights as other free functions. Er=
ror messages can explain whats going on - "extension methods can't access p=
rivate members"- so I don't see how it could be confusing.=20
<br>
<br>This is a given.
<br>
<br>> My suggestion for syntax would simply be to allow declaring a func=
tion as normal, without it needing to have been prototyped inside the class=
; but I also like the 'explicit this pointer argument' idea mentioned elsew=
here.
<br>
<br>It sounds like you=E2=80=99ve already started researching existing lite=
rature :)
<br>
<br>Now is a good time to be submitting proposals, because we=E2=80=99re ea=
rly in the development cycle targeting the 2017 standard edition.
<br>
<br>> void Foo::my_extention_method(args.<wbr>..) { =
// creates a member-function for Foo.=20
<br>> this->.. // gets a Foo* this as any =
other member function would
<br>> }
<br>
<br>Hmm, if it looks too much like a regular member declaration, then it=E2=
=80=99s too easy to accidentally define a member which does not match the o=
ne declared by the header. Proper compiler diagnostics may be demoted to li=
nk errors.
<br>
<br>>> Anyway, submitting syntax alternatives into a popularity conte=
st is the easy part. The devil is in the details.
<br></blockquote><div><br></div><div> </div><blockquote class=3D"gmail=
_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;p=
adding-left: 1ex;">
<br>The nice thing about languages like Rust is simplicity, and there=E2=80=
=99s nothing wrong with it as the right tool for the job. C++ shines when y=
ou have boatloads of code that need to run as fast as possible.
<br>
<br></blockquote><div> </div></div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_429_362914.1402524952771--
.
Author: Thiago Macieira <thiago@macieira.org>
Date: Thu, 12 Jun 2014 01:26:26 +0200
Raw View
Em qua 11 jun 2014, =E0s 15:15:51, walter1234 escreveu:
> For access rights, I suggest that 'extension methods' should be the same =
as=20
> free-functions. Error messages can explain what,and why, that is, avoidin=
g
> confusion.
I think many would find it very useful if extension methods declared in the=
=20
..cpp could access the privates of the class in question and benefit from th=
e=20
friendship the class has.
I personally don't need syntactic sugar to access public functions from the=
=20
body of my extension method. It would be nice to call x.f() instead of f(x)=
,=20
but that's IMHO a minor detail.
But as a library implementer, I really need the ability to add helper=20
functions that can mutate the internals.
--=20
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Software Architect - Intel Open Source Technology Center
PGP/GPG: 0x6EF45358; fingerprint:
E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358
--=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/.
.
Author: walter lynsdale <walter2bz@gmail.com>
Date: Thu, 12 Jun 2014 09:33:43 +0100
Raw View
--f46d04138c7d2e0f9304fb9f6b4c
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
i have sympathy for the POV that you need to define private accessing
functions inside the class, because this is how encapsulation works ;
if its ok for code outside the class definition to modify its' private
details, IMO one can simply avoid using private in the first place.
- my use cases are simply wanting the convenience of 'UFCS', being able to
keep the calling convention the same when refactoring code ... when
hammering out the details of which code belongs where.. what basic
abstractions are sufficient to define the public interface in the first
place.
Its also about project layout. being able to add helpers that use a certain
type as a receiver, but may use other types: you don't want to introduce
dependancies. Foo a; Bar b; a.f(b); // foo.h/cpp and bar.h/cpp don't want
to know about each other, crossover methods can go in 'foobar.h/cpp'
On Thu, Jun 12, 2014 at 12:26 AM, Thiago Macieira <thiago@macieira.org>
wrote:
> Em qua 11 jun 2014, =C3=A0s 15:15:51, walter1234 escreveu:
> > For access rights, I suggest that 'extension methods' should be the sam=
e
> as
> > free-functions. Error messages can explain what,and why, that is,
> avoiding
> > confusion.
>
> I think many would find it very useful if extension methods declared in t=
he
> .cpp could access the privates of the class in question and benefit from
> the
> friendship the class has.
>
> I personally don't need syntactic sugar to access public functions from t=
he
> body of my extension method. It would be nice to call x.f() instead of
> f(x),
> but that's IMHO a minor detail.
>
> But as a library implementer, I really need the ability to add helper
> functions that can mutate the internals.
>
> --
> Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
> Software Architect - Intel Open Source Technology Center
> PGP/GPG: 0x6EF45358; fingerprint:
> E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358
>
> --
>
> ---
> 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
> .
> 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/.
>
--=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/.
--f46d04138c7d2e0f9304fb9f6b4c
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">i have sympathy for the POV that you need to define privat=
e accessing functions inside the class, because this is how encapsulation w=
orks ;<div>if its ok for code outside the class definition to modify its=
9; private details, IMO one can simply avoid using private in the first pla=
ce.<br>
<div><br></div><div>- my use cases are simply wanting the convenience of &#=
39;UFCS', being able to keep the calling convention the same when refac=
toring code ... when hammering out the details of which code belongs where.=
.. what basic abstractions are sufficient to define the public interface in =
the first place.</div>
</div><div><br></div><div>Its also about project layout. being able to add =
helpers that use a certain type as a receiver, but may use other types: you=
don't want to introduce dependancies. Foo a; Bar b; =C2=A0a.f(b); // f=
oo.h/cpp and bar.h/cpp don't want to know about each other, crossover m=
ethods can go in 'foobar.h/cpp'</div>
<div><br></div></div><div class=3D"gmail_extra"><br><br><div class=3D"gmail=
_quote">On Thu, Jun 12, 2014 at 12:26 AM, Thiago Macieira <span dir=3D"ltr"=
><<a href=3D"mailto:thiago@macieira.org" target=3D"_blank">thiago@maciei=
ra.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">Em qua 11 jun 2014, =C3=A0s 15:15:51, walter=
1234 escreveu:<br>
<div class=3D"">> For access rights, I suggest that 'extension metho=
ds' should be the same as<br>
> free-functions. Error messages can explain what,and why, that is, avoi=
ding<br>
> confusion.<br>
<br>
</div>I think many would find it very useful if extension methods declared =
in the<br>
..cpp could access the privates of the class in question and benefit from th=
e<br>
friendship the class has.<br>
<br>
I personally don't need syntactic sugar to access public functions from=
the<br>
body of my extension method. It would be nice to call x.f() instead of f(x)=
,<br>
but that's IMHO a minor detail.<br>
<br>
But as a library implementer, I really need the ability to add helper<br>
functions that can mutate the internals.<br>
<span class=3D"HOEnZb"><font color=3D"#888888"><br>
--<br>
Thiago Macieira - thiago (AT) <a href=3D"http://macieira.info" target=3D"_b=
lank">macieira.info</a> - thiago (AT) <a href=3D"http://kde.org" target=3D"=
_blank">kde.org</a><br>
=C2=A0 =C2=A0Software Architect - Intel Open Source Technology Center<br>
=C2=A0 =C2=A0 =C2=A0 PGP/GPG: 0x6EF45358; fingerprint:<br>
=C2=A0 =C2=A0 =C2=A0 E067 918B B660 DBD1 105C =C2=A0966C 33F5 F005 6EF4 535=
8<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" target=3D"_blan=
k">https://groups.google.com/a/isocpp.org/d/topic/std-proposals/17tP4GJbYaI=
/unsubscribe</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/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<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 <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 />
--f46d04138c7d2e0f9304fb9f6b4c--
.
Author: Miro Knejp <miro@knejp.de>
Date: Thu, 12 Jun 2014 12:07:40 +0200
Raw View
Am 12.06.2014 01:26, schrieb Thiago Macieira:
> Em qua 11 jun 2014, =E0s 15:15:51, walter1234 escreveu:
>> For access rights, I suggest that 'extension methods' should be the same=
as
>> free-functions. Error messages can explain what,and why, that is, avoidi=
ng
>> confusion.
> I think many would find it very useful if extension methods declared in t=
he
> .cpp could access the privates of the class in question and benefit from =
the
> friendship the class has.
>
> I personally don't need syntactic sugar to access public functions from t=
he
> body of my extension method. It would be nice to call x.f() instead of f(=
x),
> but that's IMHO a minor detail.
>
> But as a library implementer, I really need the ability to add helper
> functions that can mutate the internals.
>
The thing with x.f() versus f(x) is the better support with IDEs. It's=20
simply more helpful when the editor can tell one what one can do with x.=20
One spends less time reading through documentation just to find out what=20
the name of the free function was that's available for x, if at all. As=20
much as the standard probably doesn't care for IDEs and other tool=20
support, it is one of the big reasons people don't follow the advocated=20
"best practice" of prefering free functions over methods where the=20
public interface is sufficient to implement a task, unless dictated by a=20
need for ADL.
--=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/.
.
Author: David Krauss <potswa@gmail.com>
Date: Thu, 12 Jun 2014 18:15:03 +0800
Raw View
On 2014-06-12, at 6:07 PM, Miro Knejp <miro@knejp.de> wrote:
> The thing with x.f() versus f(x) is the better support with IDEs. It's si=
mply more helpful when the editor can tell one what one can do with x. One =
spends less time reading through documentation just to find out what the na=
me of the free function was that's available for x, if at all. As much as t=
he standard probably doesn't care for IDEs and other tool support, it is on=
e of the big reasons people don't follow the advocated "best practice" of p=
refering free functions over methods where the public interface is sufficie=
nt to implement a task, unless dictated by a need for ADL.
That probably has more to do with the ease of indexing closed class definit=
ions, than whether the first argument goes before or after the open paren.
--=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/.
.
Author: Miro Knejp <miro@knejp.de>
Date: Thu, 12 Jun 2014 12:30:17 +0200
Raw View
Am 12.06.2014 12:15, schrieb David Krauss:
> On 2014-06-12, at 6:07 PM, Miro Knejp <miro@knejp.de> wrote:
>
>> The thing with x.f() versus f(x) is the better support with IDEs. It's s=
imply more helpful when the editor can tell one what one can do with x. One=
spends less time reading through documentation just to find out what the n=
ame of the free function was that's available for x, if at all. As much as =
the standard probably doesn't care for IDEs and other tool support, it is o=
ne of the big reasons people don't follow the advocated "best practice" of =
prefering free functions over methods where the public interface is suffici=
ent to implement a task, unless dictated by a need for ADL.
> That probably has more to do with the ease of indexing closed class defin=
itions, than whether the first argument goes before or after the open paren=
..
>
Certainly. Though in order to write f(x) one already has to know the=20
name of f unless some clever IDE person comes up with a way to end up=20
with either x.f() or f(x) and get the same autocompletion help without=20
knowing the exact name of f beforehand. Regarding extension methods:=20
Visual Studio is capable of indexing extension methods as well as member=20
function in C#, which is certainly made easier by having extension=20
methods require the first argument being written as "f(this X x)".=20
Typing x. will list both sets, with extension methods marked as such in=20
the autocompletion list. That alone is a big help in productivity. If=20
IDE people can do that with the necessary amount of indexing work=20
without any special syntax support for C++, awesome. Something similar=20
to extension methods was already proposed for non-virtual private=20
methods declared in different translation units outside the header.=20
Allowing something similar for non-virtual public extension methods with=20
public-only access seems like a small step from that.
--=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/.
.
Author: Sean Middleditch <sean.middleditch@gmail.com>
Date: Fri, 13 Jun 2014 14:32:42 -0700 (PDT)
Raw View
------=_Part_142_30604555.1402695162795
Content-Type: text/plain; charset=UTF-8
On Thursday, June 12, 2014 3:15:23 AM UTC-7, David Krauss wrote:
>
>
> That probably has more to do with the ease of indexing closed class
> definitions, than whether the first argument goes before or after the open
> paren.
>
Not really. Any competent IDE or source completion plugin can find and
auto-complete free functions just fine. The problem comes up when you don't
actually know the name of the function you wanted, but you might be able to
either (a) recognize its name in a list of all functions that operate on
type Foo or (b) the IDE also displays documentation comments of functions
in its suggestion list. It's not at all uncommon in my experience for
someone to just type in "x." and look at a popup list or cycle through
suggested completions because they know the functionality exists (or hope
it exists) but don't know which of several possible names it's under (e.g.
did that linear algebra vector use "magnitude" or "length"? did that state
queue use "flush" or "apply" ? was that manager object using "initialize"
or "start" ?).
The problem basically boils down to "show me everything that operates on a
particular type." Member functions today are a much smaller and more
mangeable set for the human using the IDE's suggestions to work with than
free functions (especially once you remember all unconstrained templates).
An important thing to keep foremost in mind here is that a language should
strive to offer functionality to tools because the tools are striving to be
useful to humans. "Tool friendliness" by itself has no value without
careful examination of what the tool is supposed to be doing and how it is
used.
It's also worth considering alternative approaches that tools could take
and whether the language needs to change just to satisfy the status quo of
C++ tools today. An IDE could take some text like "x.f" and examine both
all member functions of decltype(x) matching "f" as well as all matching
free functions that take a decltype(x) as its first argument and - when
selected - rewrite the text as appropriate; there's no reason the IDE can't
turn "x.f" into "foo(x, " if the user selects "foo(x_t&, int, char)" from
the list of suggested completions. None do that that I know of, but that's
not the standard's fault. I don't off the top of my head know what to do
about unconstrained templates but I'm sure someone smarter than me can come
up with a good solution if they worked at it.
I'm not saying that extension methods are entirely without value, just
pointing out that the "tool friendliness" use case for them is weaker than
it might seem.
Also, there's a potential problem with extension methods which I've seen in
C# that occurs for overly permissive extensions. If I can write an
extension method for, say, every enum, then I've just added a ton of noise
to a bunch of enumerations that didn't need it, devaluing the entire point
of having the IDE suggestions in the first place. C# doesn't allow this to
get too out of hand, but C++ very easily could.
--
---
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_142_30604555.1402695162795
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Thursday, June 12, 2014 3:15:23 AM UTC-7, David Krauss =
wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8=
ex;border-left: 1px #ccc solid;padding-left: 1ex;"><br>That probably has mo=
re to do with the ease of indexing closed class definitions, than whether t=
he first argument goes before or after the open paren.
<br></blockquote><div><br></div><div>Not really. Any competent IDE or sourc=
e completion plugin can find and auto-complete free functions just fine. Th=
e problem comes up when you don't actually know the name of the function yo=
u wanted, but you might be able to either (a) recognize its name in a list =
of all functions that operate on type Foo or (b) the IDE also displays docu=
mentation comments of functions in its suggestion list. It's not at all unc=
ommon in my experience for someone to just type in "x." and look at a popup=
list or cycle through suggested completions because they know the function=
ality exists (or hope it exists) but don't know which of several possible n=
ames it's under (e.g. did that linear algebra vector use "magnitude" or "le=
ngth"? did that state queue use "flush" or "apply" ? was that manager objec=
t using "initialize" or "start" ?).</div><div><br></div><div>The problem ba=
sically boils down to "show me everything that operates on a particular typ=
e." Member functions today are a much smaller and more mangeable set for th=
e human using the IDE's suggestions to work with than free functions (espec=
ially once you remember all unconstrained templates).</div><div><br></div><=
div>An important thing to keep foremost in mind here is that a language sho=
uld strive to offer functionality to tools because the tools are striving t=
o be useful to humans. "Tool friendliness" by itself has no value without c=
areful examination of what the tool is supposed to be doing and how it is u=
sed.</div><div><br></div><div>It's also worth considering alternative appro=
aches that tools could take and whether the language needs to change just t=
o satisfy the status quo of C++ tools today. An IDE could take some text li=
ke "x.f" and examine both all member functions of decltype(x) matching "f" =
as well as all matching free functions that take a decltype(x) as its first=
argument and - when selected - rewrite the text as appropriate; there's no=
reason the IDE can't turn "x.f" into "foo(x, " if the user selects "foo(x_=
t&, int, char)" from the list of suggested completions. None do that th=
at I know of, but that's not the standard's fault. I don't off the top of m=
y head know what to do about unconstrained templates but I'm sure someone s=
marter than me can come up with a good solution if they worked at it.</div>=
<div><br></div><div>I'm not saying that extension methods are entirely with=
out value, just pointing out that the "tool friendliness" use case for them=
is weaker than it might seem.</div><div><br></div><div>Also, there's a pot=
ential problem with extension methods which I've seen in C# that occurs for=
overly permissive extensions. If I can write an extension method for, say,=
every enum, then I've just added a ton of noise to a bunch of enumerations=
that didn't need it, devaluing the entire point of having the IDE suggesti=
ons in the first place. C# doesn't allow this to get too out of hand, but C=
++ very easily could.<br></div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <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_142_30604555.1402695162795--
.
Author: walter lynsdale <walter2bz@gmail.com>
Date: Sat, 14 Jun 2014 03:11:12 +0100
Raw View
--001a11c1b31cdbef5004fbc24ecd
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
>> it is one of the big reasons people don't follow the advocated "best
practice" of prefering free functions over methods
agree with the IDE observation as a big part of the draw to methods over
functions (and hence the conflict between the two calling styles)
I wonder if the problem could actually be approached another way in an IDE
- after you type x. (expecting method autocomplete), the IDE could also
list functions that take an x as an input, and refactor the call if you
actually select one.
eg
x. [now the editor shows me foo(X x,Y y) as an option alongside any
methods]
foo(x, [if you select the 'foo' completion, the editor inserts it]
On Thu, Jun 12, 2014 at 11:07 AM, Miro Knejp <miro@knejp.de> wrote:
> Am 12.06.2014 01:26, schrieb Thiago Macieira:
>
> Em qua 11 jun 2014, =C3=A0s 15:15:51, walter1234 escreveu:
>>
>>> For access rights, I suggest that 'extension methods' should be the sam=
e
>>> as
>>> free-functions. Error messages can explain what,and why, that is,
>>> avoiding
>>> confusion.
>>>
>> I think many would find it very useful if extension methods declared in
>> the
>> .cpp could access the privates of the class in question and benefit from
>> the
>> friendship the class has.
>>
>> I personally don't need syntactic sugar to access public functions from
>> the
>> body of my extension method. It would be nice to call x.f() instead of
>> f(x),
>> but that's IMHO a minor detail.
>>
>> But as a library implementer, I really need the ability to add helper
>> functions that can mutate the internals.
>>
>> The thing with x.f() versus f(x) is the better support with IDEs. It's
> simply more helpful when the editor can tell one what one can do with x.
> One spends less time reading through documentation just to find out what
> the name of the free function was that's available for x, if at all. As
> much as the standard probably doesn't care for IDEs and other tool suppor=
t,
> it is one of the big reasons people don't follow the advocated "best
> practice" of prefering free functions over methods where the public
> interface is sufficient to implement a task, unless dictated by a need fo=
r
> ADL.
>
>
> --
>
> --- You received this message because you are subscribed to a topic in th=
e
> 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.
> 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/.
>
--=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/.
--001a11c1b31cdbef5004fbc24ecd
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div><span style=3D"font-family:arial,sans-serif;font-size=
:13px">>> it is one of the big reasons people don't follow the ad=
vocated "best practice" of prefering free functions over methods=
=C2=A0</span><br>
</div>agree with the IDE observation as a big part of the draw to methods o=
ver functions (and hence the conflict between the two calling styles)<div><=
br><div>I wonder if the problem could actually be approached another way in=
an IDE - after you type x. (expecting method autocomplete), the IDE could =
also list functions that take an x as an input, and refactor the call if yo=
u actually select one.</div>
<div>eg</div><div>x. =C2=A0[now the editor shows me =C2=A0 foo(X x,Y y) as =
an option alongside any methods]</div><div><br></div><div>foo(x, =C2=A0 =C2=
=A0[if you select the 'foo' completion, the editor inserts it]</div=
><div><br></div>
</div></div><div class=3D"gmail_extra"><br><br><div class=3D"gmail_quote">O=
n Thu, Jun 12, 2014 at 11:07 AM, Miro Knejp <span dir=3D"ltr"><<a href=
=3D"mailto:miro@knejp.de" target=3D"_blank">miro@knejp.de</a>></span> wr=
ote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">Am 12.06.2014 01:26, schrieb Thiago Macieira=
:<div class=3D""><br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
Em qua 11 jun 2014, =C3=A0s 15:15:51, walter1234 escreveu:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
For access rights, I suggest that 'extension methods' should be the=
same as<br>
free-functions. Error messages can explain what,and why, that is, avoiding<=
br>
confusion.<br>
</blockquote>
I think many would find it very useful if extension methods declared in the=
<br>
..cpp could access the privates of the class in question and benefit from th=
e<br>
friendship the class has.<br>
<br>
I personally don't need syntactic sugar to access public functions from=
the<br>
body of my extension method. It would be nice to call x.f() instead of f(x)=
,<br>
but that's IMHO a minor detail.<br>
<br>
But as a library implementer, I really need the ability to add helper<br>
functions that can mutate the internals.<br>
<br>
</blockquote></div>
The thing with x.f() versus f(x) is the better support with IDEs. It's =
simply more helpful when the editor can tell one what one can do with x. On=
e spends less time reading through documentation just to find out what the =
name of the free function was that's available for x, if at all. As muc=
h as the standard probably doesn't care for IDEs and other tool support=
, it is one of the big reasons people don't follow the advocated "=
best practice" of prefering free functions over methods where the publ=
ic interface is sufficient to implement a task, unless dictated by a need f=
or ADL.<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 =
Google 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" target=3D"_blan=
k">https://groups.google.com/a/<u></u>isocpp.org/d/topic/std-<u></u>proposa=
ls/17tP4GJbYaI/<u></u>unsubscribe</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@<u></u>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/" target=3D"_blank">http://groups.google.com/a/<u></u>isocpp.=
org/group/std-<u></u>proposals/</a>.<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 <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 />
--001a11c1b31cdbef5004fbc24ecd--
.
Author: David Krauss <potswa@gmail.com>
Date: Tue, 24 Jun 2014 17:20:44 +0800
Raw View
--Apple-Mail=_F6A3DFDD-4764-434D-8312-C2D655C10AE7
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=ISO-8859-1
On 2014-06-24, at 4:36 PM, massimo.tristano@gmail.com wrote:
> I think this feature not only does improve readability (my_string.ends_wi=
th("foo") rather than ends_with(my_string, "foo")) but I find it absolutely=
helpful in keeping classes interfaces as minimal and lean as possible.
If you want to be able to add ends_with to std::string, class-qualified loo=
kup ([class.qual] =A73.4.3.1) is going to need to somehow be informed of th=
e namespace context, or something to indicate what extensions are applicabl=
e.
Otherwise, what if two libraries define the same extension?
If you're only talking about adding extension methods to your own class, th=
en I don't understand what the example is supposed to show.
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
--Apple-Mail=_F6A3DFDD-4764-434D-8312-C2D655C10AE7
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=ISO-8859-1
<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html charset=
=3Dwindows-1252"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-=
mode: space; -webkit-line-break: after-white-space;"><br><div><div>On 2014&=
ndash;06–24, at 4:36 PM, <a href=3D"mailto:massimo.tristano@gmail.com=
">massimo.tristano@gmail.com</a> wrote:</div><br class=3D"Apple-interchange=
-newline"><blockquote type=3D"cite"><div dir=3D"ltr">I think this feature n=
ot only does improve readability (my_string.ends_with("foo") rather than en=
ds_with(my_string, "foo")) but I find it absolutely helpful in keeping clas=
ses interfaces as minimal and lean as possible.</div></blockquote></div><br=
><div>If you want to be able to add <font face=3D"Courier">ends_with</font>=
to <font face=3D"Courier">std::string</font>, class-qualified lookup ([cla=
ss.qual] =A73.4.3.1) is going to need to somehow be informed of the namespa=
ce context, or something to indicate what extensions are applicable.</div><=
div><br></div><div>Otherwise, what if two libraries define the same extensi=
on?</div><div><br></div><div>If you’re only talking about adding exte=
nsion methods to your own class, then I don’t understand what the exa=
mple is supposed to show.</div><div><br></div></body></html>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--Apple-Mail=_F6A3DFDD-4764-434D-8312-C2D655C10AE7--
.
Author: massimo.tristano@gmail.com
Date: Tue, 24 Jun 2014 02:39:18 -0700 (PDT)
Raw View
------=_Part_2502_11944149.1403602758184
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Hi Davis, thanks for replying. Answering in order:
1) Simply put, I think the problem should be handled exactly the same way=
=20
as overloaded functions resolution, by reporting an error when the=20
resolution is ambiguous. The "extension function" should lie within the=20
same namespace of the "extended" class. In case of ambiguity, an regular,=
=20
explicit namespace::function() call would be required. Not the end of the=
=20
world.
2) Quite the contrary, I think this feature would highly benefit the design=
=20
of your own codebase. I daily work on a 10 years old codebase, and over=20
time, bit-rot has made class interfaces fatter and fatter, with a lot of=20
convenience functions made member, with the end result of making it much=20
harder to grasp what the class *really *does and what the important=20
functions are. When I raised my point about stripping out all functions=20
that do not directly interact with private members, the majority of the=20
responses were "but it's just too convenient to just type dot or arrow and=
=20
see what you can call on that object through intellisense". Since this is=
=20
what happens with practical, everyday coding on a large and old codebase,=
=20
under time restrictions, etc, this feature would keep the convenience and=
=20
solve the interface creeping problem.
So in summary, this feature would greatly improve *encapsulation *without=
=20
sacrificing *convenience*.
Thank you,
-Massimo
On Tuesday, 24 June 2014 10:20:52 UTC+1, David Krauss wrote:
>
>
> On 2014=E2=80=9306=E2=80=9324, at 4:36 PM, massimo....@gmail.com <javascr=
ipt:> wrote:
>
> I think this feature not only does improve readability=20
> (my_string.ends_with("foo") rather than ends_with(my_string, "foo")) but =
I=20
> find it absolutely helpful in keeping classes interfaces as minimal and=
=20
> lean as possible.
>
>
> If you want to be able to add ends_with to std::string, class-qualified=
=20
> lookup ([class.qual] =C2=A73.4.3.1) is going to need to somehow be inform=
ed of=20
> the namespace context, or something to indicate what extensions are=20
> applicable.
>
> Otherwise, what if two libraries define the same extension?
>
> If you=E2=80=99re only talking about adding extension methods to your own=
class,=20
> then I don=E2=80=99t understand what the example is supposed to show.
>
>
--=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/.
------=_Part_2502_11944149.1403602758184
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Hi Davis, thanks for replying. Answering in order:<div><br=
></div><div>1) Simply put, I think the problem should be handled exactly th=
e same way as overloaded functions resolution, by reporting an error when t=
he resolution is ambiguous. The "extension function" should lie within the =
same namespace of the "extended" class. In case of ambiguity, an =
regular, explicit <font face=3D"courier new, monospace">namespace::function=
()</font> call would be required. Not the end of the world.</div><div><br><=
/div><div>2) Quite the contrary, I think this feature would highly benefit =
the design of your own codebase. I daily work on a 10 years old codebase, a=
nd over time, bit-rot has made class interfaces fatter and fatter, with a l=
ot of convenience functions made member, with the end result of making it m=
uch harder to grasp what the class <i>really </i>does and what the importan=
t functions are. When I raised my point about stripping out all functions t=
hat do not directly interact with private members, the majority of the resp=
onses were "but it's just too convenient to just type dot or arrow and see =
what you can call on that object through intellisense". Since this is what =
happens with practical, everyday coding on a large and old codebase, under =
time restrictions, etc, this feature would keep the convenience and solve t=
he interface creeping problem.</div><div><br></div><div>So in summary, this=
feature would greatly improve <i>encapsulation </i>without sacrificing <i>=
convenience</i>.</div><div><br></div><div>Thank you,</div><div>-Massimo</di=
v><div><div><br>On Tuesday, 24 June 2014 10:20:52 UTC+1, David Krauss wrot=
e:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;b=
order-left: 1px #ccc solid;padding-left: 1ex;"><div style=3D"word-wrap:brea=
k-word"><br><div><div>On 2014=E2=80=9306=E2=80=9324, at 4:36 PM, <a href=3D=
"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"ON8Qr950WZgJ" onmo=
usedown=3D"this.href=3D'javascript:';return true;" onclick=3D"this.href=3D'=
javascript:';return true;">massimo....@gmail.com</a> wrote:</div><br><block=
quote type=3D"cite"><div dir=3D"ltr">I think this feature not only does imp=
rove readability (my_string.ends_with("foo") rather than ends_with(my_strin=
g, "foo")) but I find it absolutely helpful in keeping classes interfaces a=
s minimal and lean as possible.</div></blockquote></div><br><div>If you wan=
t to be able to add <font face=3D"Courier">ends_with</font> to <font face=
=3D"Courier">std::string</font>, class-qualified lookup ([class.qual] =C2=
=A73.4.3.1) is going to need to somehow be informed of the namespace contex=
t, or something to indicate what extensions are applicable.</div><div><br><=
/div><div>Otherwise, what if two libraries define the same extension?</div>=
<div><br></div><div>If you=E2=80=99re only talking about adding extension m=
ethods to your own class, then I don=E2=80=99t understand what the example =
is supposed to show.</div><div><br></div></div></blockquote></div></div></d=
iv>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_2502_11944149.1403602758184--
.
Author: massimo.tristano@gmail.com
Date: Tue, 24 Jun 2014 02:49:35 -0700 (PDT)
Raw View
------=_Part_2508_6398487.1403603375399
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
A final clarification: the examples should show a general appropriate usage=
=20
of this feature. Clients would be able to call "empty()" on an instance of=
=20
a vector just like they would be able to call size().
vector<*int*> ints;
//...
*assert*((ints.*size*() =3D=3D 0) =3D=3D ints.*empty*());
Although the empty functions is not defined as member. The D language works=
=20
exactly like this, without requiring any additional "extend" keyword.
A possible implementation: the compiler would try to find the "empty"=20
member function in vector<int>; if resolution fails then try to find any=20
function within vector<T> namespace called 'empty' that accepts a=20
vector<int> as argument. If that fails too, see if there exists a function=
=20
called "empty" callable from current scope (without any namespace=20
specification, either because the function does not lie in a namespace or=
=20
because its namespace is being used in current scope) that takes a=20
vector<T> as first and only argument.
On Tuesday, 24 June 2014 10:20:52 UTC+1, David Krauss wrote:
>
>
> On 2014=E2=80=9306=E2=80=9324, at 4:36 PM, massimo....@gmail.com <javascr=
ipt:> wrote:
>
> I think this feature not only does improve readability=20
> (my_string.ends_with("foo") rather than ends_with(my_string, "foo")) but =
I=20
> find it absolutely helpful in keeping classes interfaces as minimal and=
=20
> lean as possible.
>
>
> If you want to be able to add ends_with to std::string, class-qualified=
=20
> lookup ([class.qual] =C2=A73.4.3.1) is going to need to somehow be inform=
ed of=20
> the namespace context, or something to indicate what extensions are=20
> applicable.
>
> Otherwise, what if two libraries define the same extension?
>
> If you=E2=80=99re only talking about adding extension methods to your own=
class,=20
> then I don=E2=80=99t understand what the example is supposed to show.
>
>
--=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/.
------=_Part_2508_6398487.1403603375399
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">A final clarification: the examples should show a general =
appropriate usage of this feature. Clients would be able to call "empty()" =
on an instance of a vector just like they would be able to call size().<div=
><br></div><div><font face=3D"courier new, monospace">vector<<b>int</b>&=
gt; ints;</font></div><div><font face=3D"courier new, monospace"><br></font=
></div><div><font face=3D"courier new, monospace">//...</font></div><div><f=
ont face=3D"courier new, monospace"><br></font></div><div><font face=3D"cou=
rier new, monospace"><i>assert</i>((ints.<i>size</i>() =3D=3D 0) =3D=3D int=
s.<i>empty</i>());</font></div><div><br></div><div><br></div><div>Although =
the empty functions is not defined as member. The D language works exactly =
like this, without requiring any additional "extend" keyword.</div><div><br=
></div><div>A possible implementation: the compiler would try to find the "=
empty" member function in vector<int>; if resolution fails then try t=
o find any function within vector<T> namespace called 'empty' that ac=
cepts a vector<int> as argument. If that fails too, see if there exis=
ts a function called "empty" callable from current scope (without any names=
pace specification, either because the function does not lie in a namespace=
or because its namespace is being used in current scope) that takes a vect=
or<T> as first and only argument.</div><div><br>On Tuesday, 24 June 2=
014 10:20:52 UTC+1, David Krauss wrote:<blockquote class=3D"gmail_quote" s=
tyle=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-le=
ft: 1ex;"><div style=3D"word-wrap:break-word"><br><div><div>On 2014=E2=80=
=9306=E2=80=9324, at 4:36 PM, <a href=3D"javascript:" target=3D"_blank" gdf=
-obfuscated-mailto=3D"ON8Qr950WZgJ" onmousedown=3D"this.href=3D'javascript:=
';return true;" onclick=3D"this.href=3D'javascript:';return true;">massimo.=
....@gmail.com</a> wrote:</div><br><blockquote type=3D"cite"><div dir=3D"ltr=
">I think this feature not only does improve readability (my_string.ends_wi=
th("foo") rather than ends_with(my_string, "foo")) but I find it absolutely=
helpful in keeping classes interfaces as minimal and lean as possible.</di=
v></blockquote></div><br><div>If you want to be able to add <font face=3D"C=
ourier">ends_with</font> to <font face=3D"Courier">std::string</font>, clas=
s-qualified lookup ([class.qual] =C2=A73.4.3.1) is going to need to somehow=
be informed of the namespace context, or something to indicate what extens=
ions are applicable.</div><div><br></div><div>Otherwise, what if two librar=
ies define the same extension?</div><div><br></div><div>If you=E2=80=99re o=
nly talking about adding extension methods to your own class, then I don=E2=
=80=99t understand what the example is supposed to show.</div><div><br></di=
v></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_2508_6398487.1403603375399--
.
Author: walter lynsdale <walter2bz@gmail.com>
Date: Tue, 24 Jun 2014 11:35:15 +0100
Raw View
--089e01177699ecca8e04fc9283b3
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
>>A possible implementation: the compiler would try to find the "empty"
member function in vector<int>; if resolution fails then try to find any
function within vector<T> namespace called 'empty' that accepts a
vector<int> as argument.
+1 ... I really like this idea.
although we have a backward compatibility hazard, it would be nice if it
warned you when your extensions are shadowed by new library methods, and
that would apply to existing free-function overloads that happen to share a
name with existing methods. Maybe a keyword could quiet such warnings ..
(either add something to enable a free function as an extention method,
or disable it)
On Tue, Jun 24, 2014 at 10:49 AM, <massimo.tristano@gmail.com> wrote:
> A final clarification: the examples should show a general appropriate
> usage of this feature. Clients would be able to call "empty()" on an
> instance of a vector just like they would be able to call size().
>
> vector<*int*> ints;
>
> //...
>
> *assert*((ints.*size*() =3D=3D 0) =3D=3D ints.*empty*());
>
>
> Although the empty functions is not defined as member. The D language
> works exactly like this, without requiring any additional "extend" keywor=
d.
>
> A possible implementation: the compiler would try to find the "empty"
> member function in vector<int>; if resolution fails then try to find any
> function within vector<T> namespace called 'empty' that accepts a
> vector<int> as argument. If that fails too, see if there exists a functio=
n
> called "empty" callable from current scope (without any namespace
> specification, either because the function does not lie in a namespace or
> because its namespace is being used in current scope) that takes a
> vector<T> as first and only argument.
>
> On Tuesday, 24 June 2014 10:20:52 UTC+1, David Krauss wrote:
>
>>
>> On 2014=E2=80=9306=E2=80=9324, at 4:36 PM, massimo....@gmail.com wrote:
>>
>> 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.
>>
>>
>> If you want to be able to add ends_with to std::string, class-qualified
>> lookup ([class.qual] =C2=A73.4.3.1) is going to need to somehow be infor=
med of
>> the namespace context, or something to indicate what extensions are
>> applicable.
>>
>> Otherwise, what if two libraries define the same extension?
>>
>> If you=E2=80=99re only talking about adding extension methods to your ow=
n class,
>> then I don=E2=80=99t understand what the example is supposed to show.
>>
>> --
>
> ---
> 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
> .
> 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/.
>
--=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/.
--089e01177699ecca8e04fc9283b3
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><span style=3D"font-family:arial,sans-serif;font-size:13px=
">>>A possible implementation: the compiler would try to find the &qu=
ot;empty" member function in vector<int>; if resolution fails th=
en try to find any function within vector<T> namespace called 'em=
pty' that accepts a vector<int> as argument.=C2=A0</span><div>
<font face=3D"arial, sans-serif"><br></font><div><span style=3D"font-family=
:arial,sans-serif;font-size:13px">+1 ... I really like this idea.=C2=A0</sp=
an></div></div><div><br></div><div><font face=3D"arial, sans-serif">althoug=
h we have a backward=C2=A0compatibility hazard, it would be nice if it warn=
ed you when your=C2=A0extensions are shadowed by new library methods, and t=
hat would apply to existing free-function overloads that happen to share a =
name with existing methods. Maybe a keyword could quiet such warnings .. (e=
ither add=C2=A0something to enable a free function as an=C2=A0extention met=
hod, or=C2=A0disable it)</font></div>
<div><span style=3D"font-family:arial,sans-serif;font-size:13px"><br></span=
></div></div><div class=3D"gmail_extra"><br><br><div class=3D"gmail_quote">=
On Tue, Jun 24, 2014 at 10:49 AM, <span dir=3D"ltr"><<a href=3D"mailto:=
massimo.tristano@gmail.com" target=3D"_blank">massimo.tristano@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">A final clarification: the =
examples should show a general appropriate usage of this feature. Clients w=
ould be able to call "empty()" on an instance of a vector just li=
ke they would be able to call size().<div>
<br></div><div><font face=3D"courier new, monospace">vector<<b>int</b>&g=
t; ints;</font></div><div><font face=3D"courier new, monospace"><br></font>=
</div><div><font face=3D"courier new, monospace">//...</font></div><div><fo=
nt face=3D"courier new, monospace"><br>
</font></div><div><font face=3D"courier new, monospace"><i>assert</i>((ints=
..<i>size</i>() =3D=3D 0) =3D=3D ints.<i>empty</i>());</font></div><div><br>=
</div><div><br></div><div>Although the empty functions is not defined as me=
mber. The D language works exactly like this, without requiring any additio=
nal "extend" keyword.</div>
<div><br></div><div>A possible implementation: the compiler would try to fi=
nd the "empty" member function in vector<int>; if resolutio=
n fails then try to find any function within vector<T> namespace call=
ed 'empty' that accepts a vector<int> as argument. If that fa=
ils too, see if there exists a function called "empty" callable f=
rom current scope (without any namespace specification, either because the =
function does not lie in a namespace or because its namespace is being used=
in current scope) that takes a vector<T> as first and only argument.=
</div>
<div><div class=3D""><br>On Tuesday, 24 June 2014 10:20:52 UTC+1, David Kra=
uss wrote:</div><div><div class=3D"h5"><blockquote class=3D"gmail_quote" s=
tyle=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:=
1ex">
<div style=3D"word-wrap:break-word"><br><div><div>On 2014=E2=80=9306=E2=80=
=9324, at 4:36 PM, <a>massimo....@gmail.com</a> wrote:</div><br><blockquote=
type=3D"cite"><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 find it absolutely helpful in keeping class=
es interfaces as minimal and lean as possible.</div>
</blockquote></div><br><div>If you want to be able to add <font face=3D"Cou=
rier">ends_with</font> to <font face=3D"Courier">std::string</font>, class-=
qualified lookup ([class.qual] =C2=A73.4.3.1) is going to need to somehow b=
e informed of the namespace context, or something to indicate what extensio=
ns are applicable.</div>
<div><br></div><div>Otherwise, what if two libraries define the same extens=
ion?</div><div><br></div><div>If you=E2=80=99re only talking about adding e=
xtension methods to your own class, then I don=E2=80=99t understand what th=
e example is supposed to show.</div>
<div><br></div></div></blockquote></div></div></div></div><div class=3D"HOE=
nZb"><div class=3D"h5">
<p></p>
-- <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" target=3D"_blan=
k">https://groups.google.com/a/isocpp.org/d/topic/std-proposals/17tP4GJbYaI=
/unsubscribe</a>.<br>
To unsubscribe from this group and all its topics, send an email to <a href=
=3D"mailto:std-proposals+unsubscribe@isocpp.org" target=3D"_blank">std-prop=
osals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<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 <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 />
--089e01177699ecca8e04fc9283b3--
.