------=_Part_162_2066647656.1456485400437
Content-Type: multipart/alternative;
 boundary="----=_Part_163_1285772323.1456485400437"

------=_Part_163_1285772323.1456485400437
Content-Type: text/plain; charset=UTF-8

Okay, so here's the question. Modules are completely decoupled from files
per current proposal.
But. Do we really need that degree of flexibility?
Making module-per-file would allow such nice things as "single compilation
root", where we tell compiler to compile exactly one file, and then it
deduces all other needed components via import directives. Nice and easy.
Also, tying module to file and making each module after file would make
building hierarchies much easier, and easy for human to track and
understand.

Next. Module imports don't introduce namespaces. But. In fact, to make code
nice to use, we would then need to add namespace to each module. And watch
them not clash.

To be clear. I compare C++ module proposal to Rust module model. Latter is
easy to write, easy to understand, easy to maintain. Where former one
solves visibility but retains legacy naming clutter.

--
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/bd687912-4514-4dd5-90b2-378c68ec3f2b%40isocpp.org.

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

<div dir=3D"ltr">Okay, so here&#39;s the question. Modules are completely d=
ecoupled from files per current proposal.<br>But. Do we really need that de=
gree of flexibility?<br>Making module-per-file would allow such nice things=
 as &quot;single compilation root&quot;, where we tell compiler to compile =
exactly one file, and then it deduces all other needed components via impor=
t directives. Nice and easy.<br>Also, tying module to file and making each =
module after file would make building hierarchies much easier, and easy for=
 human to track and understand.<br><br>Next. Module imports don&#39;t intro=
duce namespaces. But. In fact, to make code nice to use, we would then need=
 to add namespace to each module. And watch them not clash.<br><br>To be cl=
ear. I compare C++ module proposal to Rust module model. Latter is easy to =
write, easy to understand, easy to maintain. Where former one solves visibi=
lity but retains legacy naming clutter.<br><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/bd687912-4514-4dd5-90b2-378c68ec3f2b%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/bd687912-4514-4dd5-90b2-378c68ec3f2b=
%40isocpp.org</a>.<br />

------=_Part_163_1285772323.1456485400437--
------=_Part_162_2066647656.1456485400437--

.

------=_Part_453_928772354.1456497939179
Content-Type: multipart/alternative;
 boundary="----=_Part_454_1420794015.1456497939180"

------=_Part_454_1420794015.1456497939180
Content-Type: text/plain; charset=UTF-8



On Friday, February 26, 2016 at 6:16:40 AM UTC-5, Igor Baidiuk wrote:
>
> Okay, so here's the question. Modules are completely decoupled from files
> per current proposal.
> But. Do we really need that degree of flexibility?
>

If you want modules to be useful, yes.

Making module-per-file would allow such nice things as "single compilation
> root", where we tell compiler to compile exactly one file, and then it
> deduces all other needed components via import directives. Nice and easy.
>

Which would require everyone to rewrite and restructure all of their code
completely just to be able to use modules.

Not gonna happen.

Also, tying module to file and making each module after file would make
> building hierarchies much easier, and easy for human to track and
> understand.
>

See above.

Next. Module imports don't introduce namespaces. But. In fact, to make code
> nice to use, we would then need to add namespace to each module. And watch
> them not clash.
>

Why would you need to add a namespace to a module, unless that module
actually adds constructs to that namespace?

To be clear. I compare C++ module proposal to Rust module model. Latter is
> easy to write, easy to understand, easy to maintain. Where former one
> solves visibility but retains legacy naming clutter.
>

That "legacy naming clutter" is called "billions of lines of C++".
Expecting people to do massive rewrites of their code is just not
practical.

--
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/d850bd4c-a151-475e-9eff-56df041cf4ed%40isocpp.org.

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

<div dir=3D"ltr"><br><br>On Friday, February 26, 2016 at 6:16:40 AM UTC-5, =
Igor Baidiuk wrote:<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">Okay, so here&#39;s the question. Modules are completely decoupled fr=
om files per current proposal.<br>But. Do we really need that degree of fle=
xibility?<br></div></blockquote><div><br>If you want modules to be useful, =
yes.<br><br></div><blockquote class=3D"gmail_quote" style=3D"margin: 0;marg=
in-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"=
ltr">Making module-per-file would allow such nice things as &quot;single co=
mpilation root&quot;, where we tell compiler to compile exactly one file, a=
nd then it deduces all other needed components via import directives. Nice =
and easy.<br></div></blockquote><div><br>Which would require everyone to re=
write and restructure all of their code completely just to be able to use m=
odules.<br><br>Not gonna happen.<br><br></div><blockquote class=3D"gmail_qu=
ote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padd=
ing-left: 1ex;"><div dir=3D"ltr">Also, tying module to file and making each=
 module after file would make building hierarchies much easier, and easy fo=
r human to track and understand.<br></div></blockquote><div><br>See above.<=
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">=
Next. Module imports don&#39;t introduce namespaces. But. In fact, to make =
code nice to use, we would then need to add namespace to each module. And w=
atch them not clash.<br></div></blockquote><div><br>Why would you need to a=
dd a namespace to a module, unless that module actually adds constructs to =
that namespace?<br><br></div><blockquote class=3D"gmail_quote" style=3D"mar=
gin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><=
div dir=3D"ltr">To be clear. I compare C++ module proposal to Rust module m=
odel. Latter is easy to write, easy to understand, easy to maintain. Where =
former one solves visibility but retains legacy naming clutter.<br></div></=
blockquote><div><br>That &quot;legacy naming clutter&quot; is called &quot;=
billions of lines of C++&quot;. Expecting people to do massive rewrites of =
their code is just not practical. <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/d850bd4c-a151-475e-9eff-56df041cf4ed%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/d850bd4c-a151-475e-9eff-56df041cf4ed=
%40isocpp.org</a>.<br />

------=_Part_454_1420794015.1456497939180--
------=_Part_453_928772354.1456497939179--

.

------=_Part_159_586486878.1456499606765
Content-Type: multipart/alternative;
 boundary="----=_Part_160_658852636.1456499606772"

------=_Part_160_658852636.1456499606772
Content-Type: text/plain; charset=UTF-8

Ok, I think I understood that the main problem is ability to add any
declaration virtually anywhere into your code.
Like, today we can have generic template decl and several specializations
in one header, and more specializations in another.
So we have yet another partial solution. Sad but true.

On Friday, February 26, 2016 at 4:45:39 PM UTC+2, Nicol Bolas wrote:
>
>
>
> On Friday, February 26, 2016 at 6:16:40 AM UTC-5, Igor Baidiuk wrote:
>>
>> Okay, so here's the question. Modules are completely decoupled from files
>> per current proposal.
>> But. Do we really need that degree of flexibility?
>>
>
> If you want modules to be useful, yes.
>

> Making module-per-file would allow such nice things as "single compilation
>> root", where we tell compiler to compile exactly one file, and then it
>> deduces all other needed components via import directives. Nice and easy.
>>
>
> Which would require everyone to rewrite and restructure all of their code
> completely just to be able to use modules.
>

> Not gonna happen.
>
> Also, tying module to file and making each module after file would make
>> building hierarchies much easier, and easy for human to track and
>> understand.
>>
>
> See above.
>
> Next. Module imports don't introduce namespaces. But. In fact, to make
>> code nice to use, we would then need to add namespace to each module. And
>> watch them not clash.
>>
>
> Why would you need to add a namespace to a module, unless that module
> actually adds constructs to that namespace?
>
> To be clear. I compare C++ module proposal to Rust module model. Latter is
>> easy to write, easy to understand, easy to maintain. Where former one
>> solves visibility but retains legacy naming clutter.
>>
>
> That "legacy naming clutter" is called "billions of lines of C++".
> Expecting people to do massive rewrites of their code is just not
> practical.
>

--
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/0a74164c-3145-45eb-ad3b-cbf29a77fa7d%40isocpp.org.

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

<div dir=3D"ltr">Ok, I think I understood that the main problem is ability =
to add any declaration virtually anywhere into your code.<br>Like, today we=
 can have generic template decl and several specializations in one header, =
and more specializations in another.<br>So we have yet another partial solu=
tion. Sad but true.<br><br>On Friday, February 26, 2016 at 4:45:39 PM UTC+2=
, Nicol Bolas wrote:<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"><br><br>On Friday, February 26, 2016 at 6:16:40 AM UTC-5, 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">Okay, s=
o here&#39;s the question. Modules are completely decoupled from files per =
current proposal.<br>But. Do we really need that degree of flexibility?<br>=
</div></blockquote><div><br>If you want modules to be useful, yes.<br></div=
></div></blockquote><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"><br><blockquote class=3D"gmail_quote" style=3D"margin:0;margin-lef=
t:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">Makin=
g module-per-file would allow such nice things as &quot;single compilation =
root&quot;, where we tell compiler to compile exactly one file, and then it=
 deduces all other needed components via import directives. Nice and easy.<=
br></div></blockquote><div><br>Which would require everyone to rewrite and =
restructure all of their code completely just to be able to use modules.<br=
></div></div></blockquote><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><br>Not gonna happen.<br><br></div><blockquote class=3D"g=
mail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;=
padding-left:1ex"><div dir=3D"ltr">Also, tying module to file and making ea=
ch module after file would make building hierarchies much easier, and easy =
for human to track and understand.<br></div></blockquote><div><br>See above=
..<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">Nex=
t. Module imports don&#39;t introduce namespaces. But. In fact, to make cod=
e nice to use, we would then need to add namespace to each module. And watc=
h them not clash.<br></div></blockquote><div><br>Why would you need to add =
a namespace to a module, unless that module actually adds constructs to tha=
t namespace?<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">To be clear. I compare C++ module proposal to Rust module model. L=
atter is easy to write, easy to understand, easy to maintain. Where former =
one solves visibility but retains legacy naming clutter.<br></div></blockqu=
ote><div><br>That &quot;legacy naming clutter&quot; is called &quot;billion=
s of lines of C++&quot;. Expecting people to do massive rewrites of their c=
ode is just not practical. <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/0a74164c-3145-45eb-ad3b-cbf29a77fa7d%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/0a74164c-3145-45eb-ad3b-cbf29a77fa7d=
%40isocpp.org</a>.<br />

------=_Part_160_658852636.1456499606772--
------=_Part_159_586486878.1456499606765--

.

------=_Part_887_1650193595.1456505199137
Content-Type: multipart/alternative;
 boundary="----=_Part_888_418514256.1456505199137"

------=_Part_888_418514256.1456505199137
Content-Type: text/plain; charset=UTF-8

On Friday, February 26, 2016 at 10:13:26 AM UTC-5, Igor Baidiuk wrote:
>
> Ok, I think I understood that the main problem is ability to add any
> declaration virtually anywhere into your code.
> Like, today we can have generic template decl and several specializations
> in one header, and more specializations in another.
> So we have yet another partial solution. Sad but true.
>

Modules is not, and never has been, intended to solve that problem. Indeed,
I'm pretty sure that the ability to add template specializations outside of
the code that defined the original is a *feature*, not a bug.

--
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/00e0a3ea-1171-4a7b-af8c-5b3f2d0842f7%40isocpp.org.

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

<div dir=3D"ltr">On Friday, February 26, 2016 at 10:13:26 AM UTC-5, Igor Ba=
idiuk wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-lef=
t: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr">O=
k, I think I understood that the main problem is ability to add any declara=
tion virtually anywhere into your code.<br>Like, today we can have generic =
template decl and several specializations in one header, and more specializ=
ations in another.<br>So we have yet another partial solution. Sad but true=
..<br></div></blockquote><div><br>Modules is not, and never has been, intend=
ed to solve that problem. Indeed, I&#39;m pretty sure that the ability to a=
dd template specializations outside of the code that defined the original i=
s a <i>feature</i>, not a bug.<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/00e0a3ea-1171-4a7b-af8c-5b3f2d0842f7%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/00e0a3ea-1171-4a7b-af8c-5b3f2d0842f7=
%40isocpp.org</a>.<br />

------=_Part_888_418514256.1456505199137--
------=_Part_887_1650193595.1456505199137--

.

On sexta-feira, 26 de fevereiro de 2016 03:16:40 PST Igor Baidiuk wrote:
> Okay, so here's the question. Modules are completely decoupled from files
> per current proposal.

What do you mean by "file" here? Many compilers are expected to save the module
information in one or more files, so files are obviously not decoupled from
modules.

I'm not trying to be obtuse here. I simply didn't understand what you're
talking about.

--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center

--
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/4630317.gkaYxBQTOS%40tjmaciei-mobl4.

.

------=_Part_3221_1170204300.1456708874938
Content-Type: multipart/alternative;
 boundary="----=_Part_3222_1504663746.1456708874939"

------=_Part_3222_1504663746.1456708874939
Content-Type: text/plain; charset=UTF-8

Not decoupled from files? Then repeat typing on command lines and import
directives? Or do you want another Java?
Core C++ has little knowledge on source layout. (Note that headers are *not
*required to be files.) You have to add too many things to make it "nice
and easy".
Rather than a newly designed language, standardization of a module system
without the actual build systems in your way is not feasible. Rust (with
only one obvious impl) is simply not comparable.
And how to integrate your nice and easy way into current projects? What if
namespaces eventually clash... rewrite every translation unit *manually*?

--
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/62b7d2c0-1072-4833-bf2e-ddc40cef565b%40isocpp.org.

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

<div dir=3D"ltr">Not decoupled from files? Then repeat typing on command li=
nes and import directives? Or do you want another Java?<br>Core C++ has lit=
tle knowledge on source layout. (Note that headers are <i>not </i>required =
to be files.) You have to add too many things to make it &quot;nice and eas=
y&quot;.<br>Rather than a newly designed language, standardization of a mod=
ule system without the actual build systems in your way is not feasible. Ru=
st (with only one obvious impl) is simply not comparable.<br>And how to int=
egrate your nice and easy way into current projects? What if namespaces eve=
ntually clash... rewrite every translation unit <i>manually</i>?<br><br></d=
iv>

<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/62b7d2c0-1072-4833-bf2e-ddc40cef565b%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/62b7d2c0-1072-4833-bf2e-ddc40cef565b=
%40isocpp.org</a>.<br />

------=_Part_3222_1504663746.1456708874939--
------=_Part_3221_1170204300.1456708874938--

.