------=_Part_2417_29956867.1368503644690
Content-Type: text/plain; charset=ISO-8859-1

I'd like to propose friend declarations that are more extensive.
Tentatively, the syntax shall be implicit friend something.

I've got a couple of motivating use cases which I would like to share.

The first is that friending functions is brittle. For any function, it may
arbitrarily hand off it's work to helper functions and such. These
implementation details are now visible because friending the function
doesn't work- for example in Visual Studio, you cannot friend
make_shared<T>, because it actually uses a factory function underneath to
construct the T. The only way to actually do this is to read the stdlib
implementation, find the helper, and friend that, which is obviously
seriously error-prone. This means that changing your implementation details
can break your API.
Secondly, if you have a tree structure represented in memory by nodes
linked via inheritance, placing a friend declaration in every single one of
them is very laborious and error-prone.

So I propose a friend declaration which has the following semantics:

When a class is friended, any class derived from that class is also
implicitly friended.
When a function is friended, any function called from that function
(recursively) is also implicitly friended.

Not having these semantics by default is useful but not having them at all
makes friend declarations difficult to use in the real world.

--

---
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_2417_29956867.1368503644690
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

I'd like to propose friend declarations that are more extensive. Tentativel=
y, the syntax shall be implicit friend something.<div><br></div><div>I've g=
ot a couple of motivating use cases which I would like to share.</div><div>=
<br></div><div>The first is that friending functions is brittle. For any fu=
nction, it may arbitrarily hand off it's work to helper functions and such.=
 These implementation details are now visible because friending the functio=
n doesn't work- for example in Visual Studio, you cannot friend make_shared=
&lt;T&gt;, because it actually uses a factory function underneath to constr=
uct the T. The only way to actually do this is to read the stdlib implement=
ation, find the helper, and friend that, which is obviously seriously error=
-prone. This means that changing your implementation details can break your=
 API.</div><div>Secondly, if you have a tree structure represented in memor=
y by nodes linked via inheritance, placing a friend declaration in every si=
ngle one of them is very laborious and error-prone.</div><div><br></div><di=
v>So I propose a friend declaration which has the following semantics:</div=
><div><br></div><div>When a class is friended, any class derived from that =
class is also implicitly friended.</div><div>When a function is friended, a=
ny function called from that function (recursively) is also implicitly frie=
nded.</div><div><br></div><div>Not having these semantics by default is use=
ful but not having them at all makes friend declarations difficult to use i=
n the real world.</div>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to 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 />
&nbsp;<br />
&nbsp;<br />

------=_Part_2417_29956867.1368503644690--

.

--20cf307d04547eed3d04dca6b2d8
Content-Type: text/plain; charset=ISO-8859-1

On Mon, May 13, 2013 at 8:54 PM, DeadMG <wolfeinstein@gmail.com> wrote:

> I'd like to propose friend declarations that are more extensive.
> Tentatively, the syntax shall be implicit friend something.
>
> I've got a couple of motivating use cases which I would like to share.
>
> The first is that friending functions is brittle. For any function, it may
> arbitrarily hand off it's work to helper functions and such. These
> implementation details are now visible because friending the function
> doesn't work- for example in Visual Studio, you cannot friend
> make_shared<T>, because it actually uses a factory function underneath to
> construct the T. The only way to actually do this is to read the stdlib
> implementation, find the helper, and friend that, which is obviously
> seriously error-prone. This means that changing your implementation details
> can break your API.
> Secondly, if you have a tree structure represented in memory by nodes
> linked via inheritance, placing a friend declaration in every single one of
> them is very laborious and error-prone.
>
> So I propose a friend declaration which has the following semantics:
>
> When a class is friended, any class derived from that class is also
> implicitly friended.
> When a function is friended, any function called from that function
> (recursively) is also implicitly friended.
>

Suppose I'm a compiler, and I see a function "foo" which uses a private
member of a class "bar" that befriends the function "baz". How am I
supposed to tell whether "baz" might possibly call "foo"? Keep in mind that
"baz" might not be defined yet (and might not even be defined in this
translation unit, and might make virtual function calls, and might make
calls through function pointers or member function pointers).


> Not having these semantics by default is useful but not having them at all
> makes friend declarations difficult to use in the real world.
>

If it's really OK for arbitrary code which you don't control to use the
member, should it really not be public? Remember that friendship is the
second-closest relationship between two entities (after membership).

--

---
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.



--20cf307d04547eed3d04dca6b2d8
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On Mon, May 13, 2013 at 8:54 PM, DeadMG <span dir=3D"ltr">&lt;<a href=3D"ma=
ilto:wolfeinstein@gmail.com" target=3D"_blank">wolfeinstein@gmail.com</a>&g=
t;</span> wrote:<br><div class=3D"gmail_quote"><blockquote class=3D"gmail_q=
uote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1e=
x">
I&#39;d like to propose friend declarations that are more extensive. Tentat=
ively, the syntax shall be implicit friend something.<div><br></div><div>I&=
#39;ve got a couple of motivating use cases which I would like to share.</d=
iv>
<div><br></div><div>The first is that friending functions is brittle. For a=
ny function, it may arbitrarily hand off it&#39;s work to helper functions =
and such. These implementation details are now visible because friending th=
e function doesn&#39;t work- for example in Visual Studio, you cannot frien=
d make_shared&lt;T&gt;, because it actually uses a factory function underne=
ath to construct the T. The only way to actually do this is to read the std=
lib implementation, find the helper, and friend that, which is obviously se=
riously error-prone. This means that changing your implementation details c=
an break your API.</div>
<div>Secondly, if you have a tree structure represented in memory by nodes =
linked via inheritance, placing a friend declaration in every single one of=
 them is very laborious and error-prone.</div><div><br></div><div>So I prop=
ose a friend declaration which has the following semantics:</div>
<div><br></div><div>When a class is friended, any class derived from that c=
lass is also implicitly friended.</div><div>When a function is friended, an=
y function called from that function (recursively) is also implicitly frien=
ded.</div>
</blockquote><div><br></div><div>Suppose I&#39;m a compiler, and I see a fu=
nction &quot;foo&quot; which uses a private member of a class &quot;bar&quo=
t; that befriends the function &quot;baz&quot;. How am I supposed to tell w=
hether &quot;baz&quot; might possibly call &quot;foo&quot;? Keep in mind th=
at &quot;baz&quot; might not be defined yet (and might not even be defined =
in this translation unit, and might make virtual function calls, and might =
make calls through function pointers or member function pointers).</div>
<div>=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;=
border-left:1px #ccc solid;padding-left:1ex"><div>Not having these semantic=
s by default is useful but not having them at all makes friend declarations=
 difficult to use in the real world.</div>
</blockquote><div><br></div><div>If it&#39;s really OK for arbitrary code w=
hich you don&#39;t control to use the member, should it really not be publi=
c? Remember that friendship is the second-closest relationship between two =
entities (after membership).</div>
</div>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to 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 />
&nbsp;<br />
&nbsp;<br />

--20cf307d04547eed3d04dca6b2d8--

.

------=_Part_240_4585827.1368522817382
Content-Type: text/plain; charset=ISO-8859-1

Or you could just use dependency injection. That's pretty much the only way
you can have transfer of private status between functions that are not
directly known about at compile time.

`allocate_shared` *could* have done this, if it were properly defined in
terms of `allocator_traits<A>::construct` instead of placement new. Your
allocator object would be the dependency you inject, and the protection
class is effectively on who's allowed to create your allocator objects.

--

---
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_240_4585827.1368522817382
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Or you could just use dependency injection. That's pretty much the only way=
 you can have transfer of private status between functions that are not dir=
ectly known about at compile time.<br><br>`allocate_shared` <i>could</i> ha=
ve done this, if it were properly defined in terms of `allocator_traits&lt;=
A&gt;::construct` instead of placement new. Your allocator object would be =
the dependency you inject, and the protection class is effectively on who's=
 allowed to create your allocator objects.<br>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to 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 />
&nbsp;<br />
&nbsp;<br />

------=_Part_240_4585827.1368522817382--

.

2013/5/14 Nicol Bolas <jmckesson@gmail.com>:
> `allocate_shared` could have done this, if it were properly defined in terms
> of `allocator_traits<A>::construct` instead of placement new.

This is

http://cplusplus.github.io/LWG/lwg-active.html#2070

and the current P/R fixes that.

- 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.



.

------=_Part_295_14082023.1368540376807
Content-Type: text/plain; charset=ISO-8859-1

No.

Or you could just use dependency injection.


I also love writing masses of library crap to work around language issues.

If it's really OK for arbitrary code


It's not arbitrary code, it's code that I have explicitly chosen to friend.

 How am I supposed to tell whether "baz" might possibly call "foo"?


You're not. If the body of baz is not available, then it is clearly not a
template and therefore you can simply stick whatever friend declarations
you need in the definition of this class in baz's TU. The same is true of
virtual functions or function pointers or other such mechanisms- they exist
in a different problem space, generally. The mechanism is primarily
intended for templates- the body of which must (obviously) be available.

--

---
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_295_14082023.1368540376807
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

No.<div><br></div><blockquote class=3D"gmail_quote" style=3D"margin: 0px 0p=
x 0px 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204);=
 border-left-style: solid; padding-left: 1ex;">Or you could just use depend=
ency injection.</blockquote><div><br></div><div>I also love writing masses =
of library crap to work around language issues.</div><div><br></div><blockq=
uote class=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; border-left-=
width: 1px; border-left-color: rgb(204, 204, 204); border-left-style: solid=
; padding-left: 1ex;">If it's really OK for arbitrary code&nbsp;</blockquot=
e><div><br></div><div>It's not arbitrary code, it's code that I have explic=
itly chosen to friend.</div><div><br></div><blockquote class=3D"gmail_quote=
" style=3D"margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-c=
olor: rgb(204, 204, 204); border-left-style: solid; padding-left: 1ex;">&nb=
sp;How am I supposed to tell whether "baz" might possibly call "foo"?</bloc=
kquote><div><br></div><div>You're not. If the body of baz is not available,=
 then it is clearly not a template and therefore you can simply stick whate=
ver friend declarations you need in the definition of this class in baz's T=
U. The same is true of virtual functions or function pointers or other such=
 mechanisms- they exist in a different problem space, generally. The mechan=
ism is primarily intended for templates- the body of which must (obviously)=
 be available.</div>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to 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 />
&nbsp;<br />
&nbsp;<br />

------=_Part_295_14082023.1368540376807--

.

--047d7b5d9c8f5ac2a504dcae4098
Content-Type: text/plain; charset=ISO-8859-1

On 14 May 2013 17:06, DeadMG <wolfeinstein@gmail.com> wrote:

>
> If it's really OK for arbitrary code
>
>
> It's not arbitrary code, it's code that I have explicitly chosen to friend.
>

I think you're using the word "explicitly" a bit liberally there.


>
>  How am I supposed to tell whether "baz" might possibly call "foo"?
>
>
> You're not. If the body of baz is not available, then it is clearly not a
> template and therefore you can simply stick whatever friend declarations
> you need in the definition of this class in baz's TU. The same is true of
> virtual functions or function pointers or other
>

How's that different from sticking whatever necessary friend declaration
into the class definition in general?

I think I would be interested in considering inheritable friendship. This
function-transient friendship, not so much.

--

---
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.



--047d7b5d9c8f5ac2a504dcae4098
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><br><div class=3D"gmail=
_quote">On 14 May 2013 17:06, DeadMG <span dir=3D"ltr">&lt;<a href=3D"mailt=
o:wolfeinstein@gmail.com" target=3D"_blank">wolfeinstein@gmail.com</a>&gt;<=
/span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><br><div class=3D"im"><blockquote class=3D"g=
mail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-=
left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
If it&#39;s really OK for arbitrary code=A0</blockquote><div><br></div></di=
v><div>It&#39;s not arbitrary code, it&#39;s code that I have explicitly ch=
osen to friend.</div></blockquote><div><br></div><div>I think you&#39;re us=
ing the word &quot;explicitly&quot; a bit liberally there.<br>
=A0<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;b=
order-left:1px #ccc solid;padding-left:1ex"><div class=3D"im"><div><br></di=
v><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;borde=
r-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid=
;padding-left:1ex">
=A0How am I supposed to tell whether &quot;baz&quot; might possibly call &q=
uot;foo&quot;?</blockquote><div><br></div></div><div>You&#39;re not. If the=
 body of baz is not available, then it is clearly not a template and theref=
ore you can simply stick whatever friend declarations you need in the defin=
ition of this class in baz&#39;s TU. The same is true of virtual functions =
or function pointers or other </div>
</blockquote><div><br></div><div>How&#39;s that different from sticking wha=
tever necessary friend declaration into the class definition in general?<br=
><br></div><div>I think I would be interested in considering inheritable fr=
iendship. This function-transient friendship, not so much.<br>
</div></div><br></div></div>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to 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 />
&nbsp;<br />
&nbsp;<br />

--047d7b5d9c8f5ac2a504dcae4098--

.

------=_Part_406_29079502.1368544236016
Content-Type: text/plain; charset=ISO-8859-1

As I understand you propose friend declarations with implicitly extended
effect, so they allow access from derived classes of a befriended one and
(more controversial apparrently) from template functions called by the
befriended type/function. This should be fully orthogonal to my proposal<https://groups.google.com/a/isocpp.org/forum/?fromgroups#!topic/std-proposals/U8Nviai2svg>,
which would allow (recursive) importing of friend declarations from the
befriended scope (which can only be a class atm).

How about "export friend <...>" for syntax. That wouldn't require a new
keyword and export should be free after exported templates are removed from
the standard now?

Or, like Ville suggested, if only the inherited friendship part would be
kept, maybe "protected friend" or "public friend"? That may not the
clearest construct...

On Tuesday, 14 May 2013 05:54:04 UTC+2, DeadMG wrote:
>
> I'd like to propose friend declarations that are more extensive.
> Tentatively, the syntax shall be implicit friend something.
>
> I've got a couple of motivating use cases which I would like to share.
>
> The first is that friending functions is brittle. For any function, it may
> arbitrarily hand off it's work to helper functions and such. These
> implementation details are now visible because friending the function
> doesn't work- for example in Visual Studio, you cannot friend
> make_shared<T>, because it actually uses a factory function underneath to
> construct the T. The only way to actually do this is to read the stdlib
> implementation, find the helper, and friend that, which is obviously
> seriously error-prone. This means that changing your implementation details
> can break your API.
> Secondly, if you have a tree structure represented in memory by nodes
> linked via inheritance, placing a friend declaration in every single one of
> them is very laborious and error-prone.
>
> So I propose a friend declaration which has the following semantics:
>
> When a class is friended, any class derived from that class is also
> implicitly friended.
> When a function is friended, any function called from that function
> (recursively) is also implicitly friended.
>
> Not having these semantics by default is useful but not having them at all
> makes friend declarations difficult to use in the real world.
>

--

---
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_406_29079502.1368544236016
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div>As I understand you propose friend declarations
with implicitly extended effect, so they allow access from derived classes =
of a befriended one and (more controversial apparrently) from template func=
tions called by the befriended type/function. This should be fully orthogon=
al to <a href=3D"https://groups.google.com/a/isocpp.org/forum/?fromgroups#!=
topic/std-proposals/U8Nviai2svg">my proposal</a>, which would allow (recurs=
ive) importing of friend declarations from the befriended scope (which can =
only be a class atm).</div><div><br></div><div>How about "export friend &lt=
;...&gt;" for syntax. That wouldn't require a new keyword and export should=
 be free after exported templates are removed from the standard now?</div><=
div><br></div><div>Or, like Ville suggested, if only the inherited friendsh=
ip part would be kept, maybe "protected friend" or "public friend"? That ma=
y not the clearest construct...</div><div><br></div>On Tuesday, 14 May 2013=
 05:54:04 UTC+2, DeadMG  wrote:<blockquote class=3D"gmail_quote" style=3D"m=
argin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"=
>I'd like to propose friend declarations that are more extensive. Tentative=
ly, the syntax shall be implicit friend something.<div><br></div><div>I've =
got a couple of motivating use cases which I would like to share.</div><div=
><br></div><div>The first is that friending functions is brittle. For any f=
unction, it may arbitrarily hand off it's work to helper functions and such=
.. These implementation details are now visible because friending the functi=
on doesn't work- for example in Visual Studio, you cannot friend make_share=
d&lt;T&gt;, because it actually uses a factory function underneath to const=
ruct the T. The only way to actually do this is to read the stdlib implemen=
tation, find the helper, and friend that, which is obviously seriously erro=
r-prone. This means that changing your implementation details can break you=
r API.</div><div>Secondly, if you have a tree structure represented in memo=
ry by nodes linked via inheritance, placing a friend declaration in every s=
ingle one of them is very laborious and error-prone.</div><div><br></div><d=
iv>So I propose a friend declaration which has the following semantics:</di=
v><div><br></div><div>When a class is friended, any class derived from that=
 class is also implicitly friended.</div><div>When a function is friended, =
any function called from that function (recursively) is also implicitly fri=
ended.</div><div><br></div><div>Not having these semantics by default is us=
eful but not having them at all makes friend declarations difficult to use =
in the real world.</div></blockquote>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to 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 />
&nbsp;<br />
&nbsp;<br />

------=_Part_406_29079502.1368544236016--

.

------=_Part_5834_28619592.1368558416144
Content-Type: text/plain; charset=ISO-8859-1


>
>
>>  How am I supposed to tell whether "baz" might possibly call "foo"?
>>
>>
>> You're not. If the body of baz is not available, then it is clearly not a
>> template and therefore you can simply stick whatever friend declarations
>> you need in the definition of this class in baz's TU. The same is true of
>> virtual functions or function pointers or other
>>
>
> How's that different from sticking whatever necessary friend declaration
> into the class definition in general?
>
> I think I would be interested in considering inheritable friendship. This
> function-transient friendship, not so much.
>

It solves the problem I described in the OP for at least some cases. The
fact that it can't solve it for ALL cases is unfortunate but not a reason
not to introduce it to solve what problems we can.

--

---
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_5834_28619592.1368558416144
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;bor=
der-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div><div cla=
ss=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 =
..8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div><br></div><bloc=
kquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-=
width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;paddin=
g-left:1ex">
&nbsp;How am I supposed to tell whether "baz" might possibly call "foo"?</b=
lockquote><div><br></div></div><div>You're not. If the body of baz is not a=
vailable, then it is clearly not a template and therefore you can simply st=
ick whatever friend declarations you need in the definition of this class i=
n baz's TU. The same is true of virtual functions or function pointers or o=
ther </div>
</blockquote><div><br></div><div>How's that different from sticking whateve=
r necessary friend declaration into the class definition in general?<br><br=
></div><div>I think I would be interested in considering inheritable friend=
ship. This function-transient friendship, not so much.</div></div></div></d=
iv></blockquote><div><br></div><div>It solves the problem I described in th=
e OP for at least some cases. The fact that it can't solve it for ALL cases=
 is unfortunate but not a reason not to introduce it to solve what problems=
 we can.&nbsp;</div>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to 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 />
&nbsp;<br />
&nbsp;<br />

------=_Part_5834_28619592.1368558416144--

.

--089e01294802763ed704dcb2b121
Content-Type: text/plain; charset=ISO-8859-1

On 14 May 2013 22:06, DeadMG <wolfeinstein@gmail.com> wrote:

>
>> I think I would be interested in considering inheritable friendship. This
>> function-transient friendship, not so much.
>>
>
> It solves the problem I described in the OP for at least some cases. The
> fact that it can't solve it for ALL cases is unfortunate but not a reason
> not to introduce it to solve what problems we can.
>
> --
>
>
It doesn't solve the problem described in the OP, unless the precondition
of make_shared is changed.
A wrapper type solves that problem as well, so why should we change the
language to accommodate
that case?

--

---
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.



--089e01294802763ed704dcb2b121
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><br><div class=3D"gmail=
_quote">On 14 May 2013 22:06, DeadMG <span dir=3D"ltr">&lt;<a href=3D"mailt=
o:wolfeinstein@gmail.com" target=3D"_blank">wolfeinstein@gmail.com</a>&gt;<=
/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"><blockquote class=3D"gmail=
_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padd=
ing-left:1ex">
<div dir=3D"ltr"><div><div class=3D"gmail_quote"><br><div>I think I would b=
e interested in considering inheritable friendship. This function-transient=
 friendship, not so much.</div></div></div></div></blockquote><div><br></di=
v>
</div><div>It solves the problem I described in the OP for at least some ca=
ses. The fact that it can&#39;t solve it for ALL cases is unfortunate but n=
ot a reason not to introduce it to solve what problems we can.=A0</div><div=
 class=3D"HOEnZb">
<div class=3D"h5">

<p></p>

--<br><br></div></div></blockquote><div><br></div><div>It doesn&#39;t solve=
 the problem described in the OP, unless the precondition of make_shared is=
 changed.<br></div><div>A wrapper type solves that problem as well, so why =
should we change the language to accommodate<br>
that case? <br></div></div><br></div></div>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to 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 />
&nbsp;<br />
&nbsp;<br />

--089e01294802763ed704dcb2b121--

.