------=_Part_22103_1070158250.1521708598964
Content-Type: multipart/alternative;
 boundary="----=_Part_22104_2102392260.1521708598964"

------=_Part_22104_2102392260.1521708598964
Content-Type: text/plain; charset="UTF-8"

Hello,

Just stumbled upon "atom" proposal, and there are some questions which bug
me quite a bit:
1. Exportability of aggregate members. There seems to be no way to say
"struct member is visible inside module, but not for outsiders".
2. There's no clear rationale for introducing yet another layering concept
of module partitions. Looks more like attempt to preserve headers.
3. Why would we ever need to have private module implementation? Can't
actual function be be put into partition or main interface, without being
exported?
4. Still, no clear rationale on why do we need single module span across
multiple TUs. Can't we have one-TU modules which form module hierarchy and
reexport symbols as needed?

Can someone point to some place where such answers can be found please? SG2
google group looks completely abandoned. My request for membership is
pending there for ~8 months, so I cannot ask anything there.

Regards,
Igor

--
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/f7d3acc1-ceda-4b2c-8c59-df556b46bf79%40isocpp.org.

------=_Part_22104_2102392260.1521708598964
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Hello,<br><br>Just stumbled upon &quot;atom&quot; proposal=
, and there are some questions which bug me quite a bit:<br>1. Exportabilit=
y of aggregate members. There seems to be no way to say &quot;struct member=
 is visible inside module, but not for outsiders&quot;.<br>2. There&#39;s n=
o clear rationale for introducing yet another layering concept of module pa=
rtitions. Looks more like attempt to preserve headers.<br>3. Why would we e=
ver need to have private module implementation? Can&#39;t actual function b=
e be put into partition or main interface, without being exported?<br>4. St=
ill, no clear rationale on why do we need single module span across multipl=
e TUs. Can&#39;t we have one-TU modules which form module hierarchy and ree=
xport symbols as needed?<br><br>Can someone point to some place where such =
answers can be found please? SG2 google group looks completely abandoned. M=
y request for membership is pending there for ~8 months, so I cannot ask an=
ything there.<br><br>Regards,<br>Igor<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/f7d3acc1-ceda-4b2c-8c59-df556b46bf79%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/f7d3acc1-ceda-4b2c-8c59-df556b46bf79=
%40isocpp.org</a>.<br />

------=_Part_22104_2102392260.1521708598964--

------=_Part_22103_1070158250.1521708598964--

.

------=_Part_23343_1298634407.1521730087426
Content-Type: multipart/alternative;
 boundary="----=_Part_23344_485453020.1521730087426"

------=_Part_23344_485453020.1521730087426
Content-Type: text/plain; charset="UTF-8"

On Thursday, March 22, 2018 at 4:49:59 AM UTC-4, Igor Baidiuk wrote:
>
> Hello,
>
> Just stumbled upon "atom" proposal, and there are some questions which bug
> me quite a bit:
> 1. Exportability of aggregate members. There seems to be no way to say
> "struct member is visible inside module, but not for outsiders".
>

I don't think that's something you can say in the current Modules TS
either. And I'm fairly sure it's not something we *want* to be able to say.

Types in C++ are not intended to be divisible in the fashion you suggest.
So if you export a type, then you export *the type*. Not parts of it. Not
individual members.

--
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/ab0a6986-183e-43c9-8874-4f2a2c32e406%40isocpp.org.

------=_Part_23344_485453020.1521730087426
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Thursday, March 22, 2018 at 4:49:59 AM UTC-4, Igor Baid=
iuk wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left:=
 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr">Hel=
lo,<br><br>Just stumbled upon &quot;atom&quot; proposal, and there are some=
 questions which bug me quite a bit:<br>1. Exportability of aggregate membe=
rs. There seems to be no way to say &quot;struct member is visible inside m=
odule, but not for outsiders&quot;.<br></div></blockquote><div><br>I don&#3=
9;t think that&#39;s something you can say in the current Modules TS either=
.. And I&#39;m fairly sure it&#39;s not something we <i>want</i> to be able =
to say.<br><br>Types in C++ are not intended to be divisible in the fashion=
 you suggest. So if you export a type, then you export <i>the type</i>. Not=
 parts of it. Not individual members.<br></div></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/ab0a6986-183e-43c9-8874-4f2a2c32e406%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/ab0a6986-183e-43c9-8874-4f2a2c32e406=
%40isocpp.org</a>.<br />

------=_Part_23344_485453020.1521730087426--

------=_Part_23343_1298634407.1521730087426--

.

--0000000000005efad40568017fa6
Content-Type: text/plain; charset="UTF-8"

In the ideal world, I would love to export concepts instead of types. Just
imagine...

--
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/CADhC_A3KLesKXjyJ3eFDit_OfkGJzKSrhnCkpMBuACWOWeB84Q%40mail.gmail.com.

--0000000000005efad40568017fa6
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">In the ideal world, I would love to export concepts instea=
d of types. Just imagine...<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/CADhC_A3KLesKXjyJ3eFDit_OfkGJzKSrhnCk=
pMBuACWOWeB84Q%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">htt=
ps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CADhC_A3KLesKXjyJ=
3eFDit_OfkGJzKSrhnCkpMBuACWOWeB84Q%40mail.gmail.com</a>.<br />

--0000000000005efad40568017fa6--

.

------=_Part_10902_413085951.1521730567907
Content-Type: multipart/alternative;
 boundary="----=_Part_10903_2101586771.1521730567907"

------=_Part_10903_2101586771.1521730567907
Content-Type: text/plain; charset="UTF-8"

Why not? It would be very convenient to have some parts of type invisible
to outsiders. Like, have class constructors which accept arguments of types
private to module. Or have some class methods public to module but private
to outsiders. ATM it requires hacks and workarounds.

On Thursday, March 22, 2018 at 4:48:07 PM UTC+2, Nicol Bolas wrote:
>
> On Thursday, March 22, 2018 at 4:49:59 AM UTC-4, Igor Baidiuk wrote:
>>
>> Hello,
>>
>> Just stumbled upon "atom" proposal, and there are some questions which
>> bug me quite a bit:
>> 1. Exportability of aggregate members. There seems to be no way to say
>> "struct member is visible inside module, but not for outsiders".
>>
>
> I don't think that's something you can say in the current Modules TS
> either. And I'm fairly sure it's not something we *want* to be able to
> say.
>
> Types in C++ are not intended to be divisible in the fashion you suggest.
> So if you export a type, then you export *the type*. Not parts of it. Not
> individual members.
>

--
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/36a216d0-518e-4b80-9749-b7114303393e%40isocpp.org.

------=_Part_10903_2101586771.1521730567907
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Why not? It would be very convenient to have some parts of=
 type invisible to outsiders. Like, have class constructors which accept ar=
guments of types private to module. Or have some class methods public to mo=
dule but private to outsiders. ATM it requires hacks and workarounds.<br><b=
r>On Thursday, March 22, 2018 at 4:48:07 PM UTC+2, Nicol Bolas wrote:<block=
quote 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">On Thursday, March =
22, 2018 at 4:49:59 AM UTC-4, Igor Baidiuk wrote:<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">Hello,<br><br>Just stumbled upon &quot;atom&=
quot; proposal, and there are some questions which bug me quite a bit:<br>1=
.. Exportability of aggregate members. There seems to be no way to say &quot=
;struct member is visible inside module, but not for outsiders&quot;.<br></=
div></blockquote><div><br>I don&#39;t think that&#39;s something you can sa=
y in the current Modules TS either. And I&#39;m fairly sure it&#39;s not so=
mething we <i>want</i> to be able to say.<br><br>Types in C++ are not inten=
ded to be divisible in the fashion you suggest. So if you export a type, th=
en you export <i>the type</i>. Not parts of it. Not individual members.<br>=
</div></div></blockquote></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/36a216d0-518e-4b80-9749-b7114303393e%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/36a216d0-518e-4b80-9749-b7114303393e=
%40isocpp.org</a>.<br />

------=_Part_10903_2101586771.1521730567907--

------=_Part_10902_413085951.1521730567907--

.

------=_Part_1025_829535722.1521733632998
Content-Type: multipart/alternative;
 boundary="----=_Part_1026_230374396.1521733632998"

------=_Part_1026_230374396.1521733632998
Content-Type: text/plain; charset="UTF-8"

On Thursday, March 22, 2018 at 10:56:08 AM UTC-4, Igor Baidiuk wrote:
>
> Why not? It would be very convenient to have some parts of type invisible
> to outsiders.
>

That sounds more like wanting a "module private" accessibility, rather than
exporting parts of a type.

Like, have class constructors which accept arguments of types private to
> module. Or have some class methods public to module but private to
> outsiders. ATM it requires hacks and workarounds.
>

--
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/04d485ee-9560-4240-8e75-fe85295453a6%40isocpp.org.

------=_Part_1026_230374396.1521733632998
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Thursday, March 22, 2018 at 10:56:08 AM UTC-4, Igor Bai=
diuk wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left=
: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr">Wh=
y not? It would be very convenient to have some parts of type invisible to =
outsiders.</div></blockquote><div><br>That sounds more like wanting a &quot=
;module private&quot; accessibility, rather than exporting parts of a type.=
<br><br></div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-l=
eft: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"=
> Like, have class constructors which accept arguments of types private to =
module. Or have some class methods public to module but private to outsider=
s. ATM it requires hacks and workarounds.</div></blockquote></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/04d485ee-9560-4240-8e75-fe85295453a6%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/04d485ee-9560-4240-8e75-fe85295453a6=
%40isocpp.org</a>.<br />

------=_Part_1026_230374396.1521733632998--

------=_Part_1025_829535722.1521733632998--

.

------=_Part_23787_1803047271.1521733746281
Content-Type: multipart/alternative;
 boundary="----=_Part_23788_1845331762.1521733746281"

------=_Part_23788_1845331762.1521733746281
Content-Type: text/plain; charset="UTF-8"

Well... yes. I meant "module private" modifier. Sorry if I described it not
clear enough.

On Thursday, March 22, 2018 at 5:47:13 PM UTC+2, Nicol Bolas wrote:
>
> On Thursday, March 22, 2018 at 10:56:08 AM UTC-4, Igor Baidiuk wrote:
>>
>> Why not? It would be very convenient to have some parts of type invisible
>> to outsiders.
>>
>
> That sounds more like wanting a "module private" accessibility, rather
> than exporting parts of a type.
>
> Like, have class constructors which accept arguments of types private to
>> module. Or have some class methods public to module but private to
>> outsiders. ATM it requires hacks and workarounds.
>>
>

--
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/4469ca74-1e18-4c26-9395-7857aa4df64f%40isocpp.org.

------=_Part_23788_1845331762.1521733746281
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Well... yes. I meant &quot;module private&quot; modifier. =
Sorry if I described it not clear enough.<br><br>On Thursday, March 22, 201=
8 at 5:47:13 PM UTC+2, Nicol Bolas wrote:<blockquote class=3D"gmail_quote" =
style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-l=
eft: 1ex;"><div dir=3D"ltr">On Thursday, March 22, 2018 at 10:56:08 AM UTC-=
4, Igor Baidiuk wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0;m=
argin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"l=
tr">Why not? It would be very convenient to have some parts of type invisib=
le to outsiders.</div></blockquote><div><br>That sounds more like wanting a=
 &quot;module private&quot; accessibility, rather than exporting parts of a=
 type.<br><br></div><blockquote class=3D"gmail_quote" style=3D"margin:0;mar=
gin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr=
"> Like, have class constructors which accept arguments of types private to=
 module. Or have some class methods public to module but private to outside=
rs. ATM it requires hacks and workarounds.</div></blockquote></div></blockq=
uote></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/4469ca74-1e18-4c26-9395-7857aa4df64f%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/4469ca74-1e18-4c26-9395-7857aa4df64f=
%40isocpp.org</a>.<br />

------=_Part_23788_1845331762.1521733746281--

------=_Part_23787_1803047271.1521733746281--

.

------=_Part_23744_616565445.1521735301245
Content-Type: multipart/alternative;
 boundary="----=_Part_23745_1520206853.1521735301245"

------=_Part_23745_1520206853.1521735301245
Content-Type: text/plain; charset="UTF-8"

On Thursday, March 22, 2018 at 11:49:06 AM UTC-4, Igor Baidiuk wrote:
>
> Well... yes. I meant "module private" modifier. Sorry if I described it
> not clear enough.
>

The problem with an explicit "private module" accessibility is that the
module system has no formal concept of "submodules".

So, a library would be defined as a module which exports some symbols. But
we want the compilation of that module to itself be able to use the module
system. Not just to include libraries but also other parts of itself. So a
library module internally might be defined by a number of conceptual
submodules, which are aggregated into a single module for export to user
code.

Because the module system doesn't formally recognize such a thing, each of
those conceptual submodules is *completely separate* from the rest. As
such, if you want to have a submodule access "private module" aspects of
some other submodule, that doesn't work. You'll have to employ those "hacks
and workarounds" you spoke of.

So such an accessibility would only be useful if you *develop* everything
in a particular library as one big module, rather than assembling it out of
smaller modules into the final form.

--
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/1e4a9bc2-42c8-4b56-8028-dbfaa268248f%40isocpp.org.

------=_Part_23745_1520206853.1521735301245
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Thursday, March 22, 2018 at 11:49:06 AM UTC-4, Igor Bai=
diuk wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left=
: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr">We=
ll... yes. I meant &quot;module private&quot; modifier. Sorry if I describe=
d it not clear enough.<br></div></blockquote><div><br>The problem with an e=
xplicit &quot;private module&quot; accessibility is that the module system =
has no formal concept of &quot;submodules&quot;.<br><br>So, a library would=
 be defined as a module which exports some symbols. But we want the compila=
tion of that module to itself be able to use the module system. Not just to=
 include libraries but also other parts of itself. So a library module inte=
rnally might be defined by a number of conceptual submodules, which are agg=
regated into a single module for export to user code.<br><br>Because the mo=
dule system doesn&#39;t formally recognize such a thing, each of those conc=
eptual submodules is <i>completely separate</i> from the rest. As such, if =
you want to have a submodule access &quot;private module&quot; aspects of s=
ome other submodule, that doesn&#39;t work. You&#39;ll have to employ those=
 &quot;hacks and workarounds&quot; you spoke of.<br><br>So such an accessib=
ility would only be useful if you <i>develop</i> everything in a particular=
 library as one big module, rather than assembling it out of smaller module=
s into the final form.</div><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/1e4a9bc2-42c8-4b56-8028-dbfaa268248f%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/1e4a9bc2-42c8-4b56-8028-dbfaa268248f=
%40isocpp.org</a>.<br />

------=_Part_23745_1520206853.1521735301245--

------=_Part_23744_616565445.1521735301245--

.

------=_Part_8756_121256200.1521736009806
Content-Type: multipart/alternative;
 boundary="----=_Part_8757_890007619.1521736009807"

------=_Part_8757_890007619.1521736009807
Content-Type: text/plain; charset="UTF-8"

Why do you think one needs to construct whole library as single module to
make "module private" useful?
One of usage examples is a type which cannot be directly constructed by
module users. ATM it requires some bogus workarounds. With "module
private", you simply make constructor module private and then use it inside
library as you please. Or make satellite factory function which can be
exported independently. No need to develop everything as single huge
module, unless you're writing highly spagghettified code.

On Thursday, March 22, 2018 at 6:15:01 PM UTC+2, Nicol Bolas wrote:
>
> On Thursday, March 22, 2018 at 11:49:06 AM UTC-4, Igor Baidiuk wrote:
>>
>> Well... yes. I meant "module private" modifier. Sorry if I described it
>> not clear enough.
>>
>
> The problem with an explicit "private module" accessibility is that the
> module system has no formal concept of "submodules".
>
> So, a library would be defined as a module which exports some symbols. But
> we want the compilation of that module to itself be able to use the module
> system. Not just to include libraries but also other parts of itself. So a
> library module internally might be defined by a number of conceptual
> submodules, which are aggregated into a single module for export to user
> code.
>
> Because the module system doesn't formally recognize such a thing, each of
> those conceptual submodules is *completely separate* from the rest. As
> such, if you want to have a submodule access "private module" aspects of
> some other submodule, that doesn't work. You'll have to employ those "hacks
> and workarounds" you spoke of.
>
> So such an accessibility would only be useful if you *develop* everything
> in a particular library as one big module, rather than assembling it out of
> smaller modules into the final form.
>
>

--
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/96878840-a3cc-4ff4-914f-be83ed3d80a1%40isocpp.org.

------=_Part_8757_890007619.1521736009807
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Why do you think one needs to construct whole library as s=
ingle module to make &quot;module private&quot; useful?<br>One of usage exa=
mples is a type which cannot be directly constructed by module users. ATM i=
t requires some bogus workarounds. With &quot;module private&quot;, you sim=
ply make constructor module private and then use it inside library as you p=
lease. Or make satellite factory function which can be exported independent=
ly. No need to develop everything as single huge module, unless you&#39;re =
writing highly spagghettified code.<br><br>On Thursday, March 22, 2018 at 6=
:15:01 PM UTC+2, Nicol Bolas wrote:<blockquote class=3D"gmail_quote" style=
=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: =
1ex;"><div dir=3D"ltr">On Thursday, March 22, 2018 at 11:49:06 AM UTC-4, Ig=
or Baidiuk wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0;margin=
-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">W=
ell... yes. I meant &quot;module private&quot; modifier. Sorry if I describ=
ed it not clear enough.<br></div></blockquote><div><br>The problem with an =
explicit &quot;private module&quot; accessibility is that the module system=
 has no formal concept of &quot;submodules&quot;.<br><br>So, a library woul=
d be defined as a module which exports some symbols. But we want the compil=
ation of that module to itself be able to use the module system. Not just t=
o include libraries but also other parts of itself. So a library module int=
ernally might be defined by a number of conceptual submodules, which are ag=
gregated into a single module for export to user code.<br><br>Because the m=
odule system doesn&#39;t formally recognize such a thing, each of those con=
ceptual submodules is <i>completely separate</i> from the rest. As such, if=
 you want to have a submodule access &quot;private module&quot; aspects of =
some other submodule, that doesn&#39;t work. You&#39;ll have to employ thos=
e &quot;hacks and workarounds&quot; you spoke of.<br><br>So such an accessi=
bility would only be useful if you <i>develop</i> everything in a particula=
r library as one big module, rather than assembling it out of smaller modul=
es into the final form.</div><br></div></blockquote></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/96878840-a3cc-4ff4-914f-be83ed3d80a1%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/96878840-a3cc-4ff4-914f-be83ed3d80a1=
%40isocpp.org</a>.<br />

------=_Part_8757_890007619.1521736009807--

------=_Part_8756_121256200.1521736009806--

.

------=_Part_22552_1042778017.1521738476929
Content-Type: multipart/alternative;
 boundary="----=_Part_22553_1893857923.1521738476929"

------=_Part_22553_1893857923.1521738476929
Content-Type: text/plain; charset="UTF-8"

On Thursday, March 22, 2018 at 12:26:49 PM UTC-4, Igor Baidiuk wrote:
>
> Why do you think one needs to construct whole library as single module to
> make "module private" useful?
>

Because the code that wants to access the "private module" member is not in
the same module as the module that defined the private module member. And
therefore, it cannot access it. That's what "private module" *means*: the
name is only accessible to other members of the same module.

One of usage examples is a type which cannot be directly constructed by
> module users. ATM it requires some bogus workarounds. With "module
> private", you simply make constructor module private and then use it inside
> library as you please.
>

Or you just create an internal module that exposes a function that
constructs the type, and you never export that module into the outer
module's interface.

Or make satellite factory function which can be exported independently. No
> need to develop everything as single huge module, unless you're writing
> highly spagghettified 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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/58700067-dcb7-4b48-a9a6-2aea7e6b6ac9%40isocpp.org.

------=_Part_22553_1893857923.1521738476929
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Thursday, March 22, 2018 at 12:26:49 PM UTC-4, Igor Bai=
diuk wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left=
: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr">Wh=
y do you think one needs to construct whole library as single module to mak=
e &quot;module private&quot; useful?<br></div></blockquote><div><br>Because=
 the code that wants to access the &quot;private module&quot; member is not=
 in the same module as the module that defined the private module member. A=
nd therefore, it cannot access it. That&#39;s what &quot;private module&quo=
t; <i>means</i>: the name is only accessible to other members of the same m=
odule.<br><br></div><blockquote class=3D"gmail_quote" style=3D"margin: 0;ma=
rgin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=
=3D"ltr">One of usage examples is a type which cannot be directly construct=
ed by module users. ATM it requires some bogus workarounds. With &quot;modu=
le private&quot;, you simply make constructor module private and then use i=
t inside library as you please.</div></blockquote><div><br>Or you just crea=
te an internal module that exposes a function that constructs the type, and=
 you never export that module into the outer module&#39;s interface.<br><br=
></div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.=
8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr">Or mak=
e satellite factory function which can be exported independently. No need t=
o develop everything as single huge module, unless you&#39;re writing highl=
y spagghettified code.</div></blockquote></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/58700067-dcb7-4b48-a9a6-2aea7e6b6ac9%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/58700067-dcb7-4b48-a9a6-2aea7e6b6ac9=
%40isocpp.org</a>.<br />

------=_Part_22553_1893857923.1521738476929--

------=_Part_22552_1042778017.1521738476929--

.

------=_Part_9888_1058375265.1521740022074
Content-Type: multipart/alternative;
 boundary="----=_Part_9889_2084622507.1521740022075"

------=_Part_9889_2084622507.1521740022075
Content-Type: text/plain; charset="UTF-8"



On Thursday, March 22, 2018 at 7:07:57 PM UTC+2, Nicol Bolas wrote:
>
> On Thursday, March 22, 2018 at 12:26:49 PM UTC-4, Igor Baidiuk wrote:
>>
>> Why do you think one needs to construct whole library as single module to
>> make "module private" useful?
>>
>
> Because the code that wants to access the "private module" member is not
> in the same module as the module that defined the private module member.
> And therefore, it cannot access it. That's what "private module" *means*:
> the name is only accessible to other members of the same module.
>

Could you please elaborate a bit on why you emphasize inability of module
private members to be accessed by other modules as their deficiency? It's
their exact purpose. To make some members of type accessible only within
module that same type was declared. If you want some shared implementation
logic, you pack it into internal module which is used across library but is
never exported.


>
> One of usage examples is a type which cannot be directly constructed by
>> module users. ATM it requires some bogus workarounds. With "module
>> private", you simply make constructor module private and then use it inside
>> library as you please.
>>
>
> Or you just create an internal module that exposes a function that
> constructs the type, and you never export that module into the outer
> module's interface.
>

What if I want some exported type be constructible only within module?
That's what "module private" modifier would do exactly.


>
> Or make satellite factory function which can be exported independently. No
>> need to develop everything as single huge module, unless you're writing
>> highly spagghettified 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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/c97d9a99-117c-4975-993c-21072ff9f9f5%40isocpp.org.

------=_Part_9889_2084622507.1521740022075
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><br>On Thursday, March 22, 2018 at 7:07:57 PM UTC+2, N=
icol Bolas wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margi=
n-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"l=
tr">On Thursday, March 22, 2018 at 12:26:49 PM UTC-4, Igor Baidiuk wrote:<b=
lockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-=
left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">Why do you think one=
 needs to construct whole library as single module to make &quot;module pri=
vate&quot; useful?<br></div></blockquote><div><br>Because the code that wan=
ts to access the &quot;private module&quot; member is not in the same modul=
e as the module that defined the private module member. And therefore, it c=
annot access it. That&#39;s what &quot;private module&quot; <i>means</i>: t=
he name is only accessible to other members of the same module.<br></div></=
div></blockquote><div><br>Could you please elaborate a bit on why you empha=
size inability of module private members to be accessed by other modules as=
 their deficiency? It&#39;s their exact purpose. To make some members of ty=
pe accessible only within module that same type was declared. If you want s=
ome shared implementation logic, you pack it into internal module which is =
used across library but is never exported.<br>=C2=A0</div><blockquote class=
=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #cc=
c solid;padding-left: 1ex;"><div dir=3D"ltr"><div><br></div><blockquote cla=
ss=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc=
 solid;padding-left:1ex"><div dir=3D"ltr">One of usage examples is a type w=
hich cannot be directly constructed by module users. ATM it requires some b=
ogus workarounds. With &quot;module private&quot;, you simply make construc=
tor module private and then use it inside library as you please.</div></blo=
ckquote><div><br>Or you just create an internal module that exposes a funct=
ion that constructs the type, and you never export that module into the out=
er module&#39;s interface.<br></div></div></blockquote><div><br>What if I w=
ant some exported type be constructible only within module? That&#39;s what=
 &quot;module private&quot; modifier would do exactly.<br>=C2=A0</div><bloc=
kquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-l=
eft: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div><br></div><bl=
ockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-l=
eft:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">Or make satellite fac=
tory function which can be exported independently. No need to develop every=
thing as single huge module, unless you&#39;re writing highly spagghettifie=
d code.</div></blockquote></div></blockquote></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/c97d9a99-117c-4975-993c-21072ff9f9f5%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/c97d9a99-117c-4975-993c-21072ff9f9f5=
%40isocpp.org</a>.<br />

------=_Part_9889_2084622507.1521740022075--

------=_Part_9888_1058375265.1521740022074--

.

------=_Part_23718_847885398.1521745564951
Content-Type: multipart/alternative;
 boundary="----=_Part_23719_1946886272.1521745564951"

------=_Part_23719_1946886272.1521745564951
Content-Type: text/plain; charset="UTF-8"

On Thursday, March 22, 2018 at 1:33:42 PM UTC-4, Igor Baidiuk wrote:
>
> On Thursday, March 22, 2018 at 7:07:57 PM UTC+2, Nicol Bolas wrote:
>>
>> On Thursday, March 22, 2018 at 12:26:49 PM UTC-4, Igor Baidiuk wrote:
>>>
>>> Why do you think one needs to construct whole library as single module
>>> to make "module private" useful?
>>>
>>
>> Because the code that wants to access the "private module" member is not
>> in the same module as the module that defined the private module member.
>> And therefore, it cannot access it. That's what "private module" *means*:
>> the name is only accessible to other members of the same module.
>>
>
> Could you please elaborate a bit on why you emphasize inability of module
> private members to be accessed by other modules as their deficiency? It's
> their exact purpose. To make some members of type accessible only within
> module that same type was declared. If you want some shared implementation
> logic, you pack it into internal module which is used across library but is
> never exported.
>

Which is the point: the distinction between a "module" and a "library".

Most libraries will likely be composed of multiple modules, but exported
under a single name. Indeed, in the ideal circumstance, each translation
unit in your project would be its own module. As such, you are far more
likely to need library-wide visibility of some construct than module-wide
visibility.

One of usage examples is a type which cannot be directly constructed by
>>> module users. ATM it requires some bogus workarounds. With "module
>>> private", you simply make constructor module private and then use it inside
>>> library as you please.
>>>
>>
>> Or you just create an internal module that exposes a function that
>> constructs the type, and you never export that module into the outer
>> module's interface.
>>
>
> What if I want some exported type be constructible only within module?
>

The class itself would be part of the module's interface, but the
non-member function that constructs one would not be part of the module's
interface. The aforementioned non-member function would be a friend of the
class.

This requires nothing more than what we currently have.


> That's what "module private" modifier would do exactly.
>
>
>>
>> Or make satellite factory function which can be exported independently.
>>> No need to develop everything as single huge module, unless you're writing
>>> highly spagghettified 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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/c7a41d4d-4388-49d4-977a-0a405476d2e9%40isocpp.org.

------=_Part_23719_1946886272.1521745564951
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Thursday, March 22, 2018 at 1:33:42 PM UTC-4, Igor Baid=
iuk wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left:=
 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr">On =
Thursday, March 22, 2018 at 7:07:57 PM UTC+2, Nicol Bolas wrote:<blockquote=
 class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px =
#ccc solid;padding-left:1ex"><div dir=3D"ltr">On Thursday, March 22, 2018 a=
t 12:26:49 PM UTC-4, Igor Baidiuk wrote:<blockquote class=3D"gmail_quote" s=
tyle=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:=
1ex"><div dir=3D"ltr">Why do you think one needs to construct whole library=
 as single module to make &quot;module private&quot; useful?<br></div></blo=
ckquote><div><br>Because the code that wants to access the &quot;private mo=
dule&quot; member is not in the same module as the module that defined the =
private module member. And therefore, it cannot access it. That&#39;s what =
&quot;private module&quot; <i>means</i>: the name is only accessible to oth=
er members of the same module.<br></div></div></blockquote><div><br>Could y=
ou please elaborate a bit on why you emphasize inability of module private =
members to be accessed by other modules as their deficiency? It&#39;s their=
 exact purpose. To make some members of type accessible only within module =
that same type was declared. If you want some shared implementation logic, =
you pack it into internal module which is used across library but is never =
exported.<br></div></div></blockquote><div><br>Which is the point: the dist=
inction between a &quot;module&quot; and a &quot;library&quot;.<br><br>Most=
 libraries will likely be composed of multiple modules, but exported under =
a single name. Indeed, in the ideal circumstance, each translation unit in =
your project would be its own module. As such, you are far more likely to n=
eed library-wide visibility of some construct than module-wide visibility.<=
br><br></div><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">=
<div></div><blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:=
0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div></=
div><blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;b=
order-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">One of usage e=
xamples is a type which cannot be directly constructed by module users. ATM=
 it requires some bogus workarounds. With &quot;module private&quot;, you s=
imply make constructor module private and then use it inside library as you=
 please.</div></blockquote><div><br>Or you just create an internal module t=
hat exposes a function that constructs the type, and you never export that =
module into the outer module&#39;s interface.<br></div></div></blockquote><=
div><br>What if I want some exported type be constructible only within modu=
le?</div></div></blockquote><div><br>The class itself would be part of the =
module&#39;s interface, but the non-member function that constructs one wou=
ld not be part of the module&#39;s interface. The aforementioned non-member=
 function would be a friend of the class.<br><br>This requires nothing more=
 than what we currently have.<br>=C2=A0</div><blockquote class=3D"gmail_quo=
te" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;paddi=
ng-left: 1ex;"><div dir=3D"ltr"><div> That&#39;s what &quot;module private&=
quot; modifier would do exactly.<br>=C2=A0</div><blockquote class=3D"gmail_=
quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;paddi=
ng-left:1ex"><div dir=3D"ltr"><div><br></div><blockquote class=3D"gmail_quo=
te" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-=
left:1ex"><div dir=3D"ltr">Or make satellite factory function which can be =
exported independently. No need to develop everything as single huge module=
, unless you&#39;re writing highly spagghettified code.</div></blockquote><=
/div></blockquote></div></blockquote></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/c7a41d4d-4388-49d4-977a-0a405476d2e9%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/c7a41d4d-4388-49d4-977a-0a405476d2e9=
%40isocpp.org</a>.<br />

------=_Part_23719_1946886272.1521745564951--

------=_Part_23718_847885398.1521745564951--

.

On 03/22/2018 09:49 AM, Igor Baidiuk wrote:
> Just stumbled upon "atom" proposal, and there are some questions which bug me quite a bit:
> 1. Exportability of aggregate members. There seems to be no way to say "struct member is visible inside module, but not for outsiders".

Do you want that struct to be a complete type on the outside?

> 2. There's no clear rationale for introducing yet another layering concept of module partitions. Looks more like attempt to preserve headers.

Module partitions allow to specify module-local interfaces.

> 3. Why would we ever need to have private module implementation? Can't actual function be be put into partition or main interface, without being exported?

Some people might have large modules and want their function definitions
in separate translation units compared to the declarations, to limit
source file size.

> 4. Still, no clear rationale on why do we need single module span across multiple TUs. Can't we have one-TU modules which form module hierarchy and reexport symbols as needed?

A single translation unit might not be the right size for everybody's taste
on how large an individual module should be.  Having an aggregation layer
between "translation unit" and "entire program" seems like an appropriate
subdivision.

Jens

--
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/5AB6436F.3080106%40gmx.net.

.