------=_Part_778_286681751.1459964705430
Content-Type: multipart/alternative;
 boundary="----=_Part_779_1794771029.1459964705430"

------=_Part_779_1794771029.1459964705430
Content-Type: text/plain; charset=UTF-8

Hi Daniele, Markus, all,

For those who have not read the paper, the authors propose a way to publish
the interface of a class without also publishing the internal details
(members and private functions); translation unit that only see the
interface can only deal with pointers and references to the partial type.
This allows bether decoupling of translation units minimizing recompilation
on changes to internal details and helps with mantaining a stable ABI.

As the authors point out, the usual solutions are virtual interfaces and
the pimpl idiom, which both have syntatic and runtime overhead. There is a
third solution, of course: simply declare, but not define the class and
implement the whole class interface via non member friend functions.
Unfortunately this loses the ability to call functions via the dot notation
and would in fact be a great application for UFC.

The idea presented in P0309R0 is good and I do not have much to say about
the semantics, so I'll bikeshed about the syntax.

The declaration syntax seems way too complicated. First of all, the
identifier seems completely superfluous. The class name already act as an
identifier and there is no need of another one. I suspect that in practice
all usages would end up as "class X : partial X " or, "class X : partial
XInterface", which is completely redundant. The claimed benefits do not
seem to match reality:
- Saving Declaration: assuming this is a desirable [see below] benefit, the
class name is enough to link the declaration with the definition.
- Hijacking: if I understand correctly, the authors want to prevent a 3rd
party from defining another partial class with extra members and then
defining the members themselves, granting access to the implementation
details. The fix unfortunately doesn't work, because if the compiler can't
see the hijacking definition while compiling the internal class, it won't
be able to flag the error. Note that one can do the same hijack today by
simply copying the definition of a class and adding their own members.

If all members were required to be re-declared in the implementation, both
issues would be come moot. In fact the best way to see a partial class is
simply as a way to forward declare member functions of an incomplete class.
As such, the partial class feature should really have no effect to the
class definition syntax, which would not need to be extended.  Thus we only
need a  way to mark what appear to be a class definition as a declaration.
As such, simply prepending the keyword public before the 'class' or
'struct' keyword is enough. This will also have the benefit of implicitly
declaring all the forward declared member functions as public (it doesn't
in fact make sense to forward declare private or protected member
functions). Hijacking is partially prevented because, as it is the case
today, the type required to be complete  (i.e. the actual definition is
visible) when a member function is defined.

HTH,

-- gpd

--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/422fa375-895e-4588-a592-b1d5cce766fc%40isocpp.org.

------=_Part_779_1794771029.1459964705430
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Hi Daniele, Markus, all,<br><br>For those who have not rea=
d the paper, the authors propose a way to publish the interface of a class =
without also publishing the internal details (members and private functions=
); translation unit that only see the interface can only deal with pointers=
 and references to the partial type. This allows bether decoupling of trans=
lation units minimizing recompilation on changes to internal details and he=
lps with mantaining a stable ABI. <br><br>As the authors point out, the usu=
al solutions are virtual interfaces and the pimpl idiom, which both have sy=
ntatic and runtime overhead. There is a third solution, of course: simply d=
eclare, but not define the class and implement the whole class interface vi=
a non member friend functions. Unfortunately this loses the ability to call=
 functions via the dot notation and would in fact be a great application fo=
r UFC.<br><br>The idea presented in P0309R0 is good and I do not have much =
to say about the semantics, so I&#39;ll bikeshed about the syntax.<br><br>T=
he declaration syntax seems way too complicated. First of all, the identifi=
er seems completely superfluous. The class name already act as an identifie=
r and there is no need of another one. I suspect that in practice all usage=
s would end up as &quot;class X : partial X &quot; or, &quot;class X : part=
ial XInterface&quot;, which is completely redundant. The claimed benefits d=
o not seem to match reality:<br>- Saving Declaration: assuming this is a de=
sirable [see below] benefit, the class name is enough to link the declarati=
on with the definition.<br>- Hijacking: if I understand correctly, the auth=
ors want to prevent a 3rd party from defining another partial class with ex=
tra members and then defining the members themselves, granting access to th=
e implementation details. The fix unfortunately doesn&#39;t work, because i=
f the compiler can&#39;t see the hijacking definition while compiling the i=
nternal class, it won&#39;t be able to flag the error. Note that one can do=
 the same hijack today by simply copying the definition of a class and addi=
ng their own members. <br><br>If all members were required to be re-declare=
d in the implementation, both issues would be come moot. In fact the best w=
ay to see a partial class is simply as a way to forward declare member func=
tions of an incomplete class. As such, the partial class feature should rea=
lly have no effect to the class definition syntax, which would not need to =
be extended.=C2=A0 Thus we only need a=C2=A0 way to mark what appear to be =
a class definition as a declaration. As such, simply prepending the keyword=
 public before the &#39;class&#39; or &#39;struct&#39; keyword is enough. T=
his will also have the benefit of implicitly declaring all the forward decl=
ared member functions as public (it doesn&#39;t in fact make sense to forwa=
rd declare private or protected member functions). Hijacking is partially p=
revented because, as it is the case today, the type required to be complete=
=C2=A0 (i.e. the actual definition is visible) when a member function is de=
fined.<br><br>HTH,<br><br>-- gpd<br></div>

<p></p>

-- <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 <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 />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/422fa375-895e-4588-a592-b1d5cce766fc%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/422fa375-895e-4588-a592-b1d5cce766fc=
%40isocpp.org</a>.<br />

------=_Part_779_1794771029.1459964705430--
------=_Part_778_286681751.1459964705430--

.