------=_Part_2100_593798603.1543353029210
Content-Type: multipart/alternative;
 boundary="----=_Part_2101_1163182435.1543353029210"

------=_Part_2101_1163182435.1543353029210
Content-Type: text/plain; charset="UTF-8"

Hi all,

I've got a question about modules since some times now.
The way modules have been done, they require the sources files to declare
which module they implements and what they exports into a preambule.
To be honest, I don't really get why this was necessary.
Moreover, i found some drawbacks with it:
- It makes sources files dependent on which modules they will be shipped in.
- Not only the sources does declare the module they belongs to, but they
also need to be put together in the build system (may it be Makefiles,
cmake, ...). This goes against the DRY concept since it cause duplication
of information.
- There is a concept of 'module interface unit' (and even a 'primary module
interface unit'!). As far as I understand it, it is almost the same that
old .h files, thus providing no real benefit over the latter when writing
new code.

So, my question is why was this preambule necessary? Can't we avoid it?
Also there seems to be a paper which  indicate that preambules are
unnecessary
(http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p1299r0.html).
What's the status about this?

Thanks,
Masse Nicolas.

--
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/e3f7a8a5-8e78-49f5-97df-139951f5d07a%40isocpp.org.

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

<div dir=3D"ltr">Hi all,<br><br>I&#39;ve got a question about modules since=
 some times now.<br>The way modules have been done, they require the source=
s files to declare which module they implements and what they exports into =
a preambule.<br>To be honest, I don&#39;t really get why this was necessary=
..<br>Moreover, i found some drawbacks with it:<br>- It makes sources files =
dependent on which modules they will be shipped in.<br>- Not only the sourc=
es does declare the module they belongs to, but they also need to be put to=
gether in the build system (may it be Makefiles, cmake, ...). This goes aga=
inst the DRY concept since it cause duplication of information.<br>- There =
is a concept of &#39;module interface unit&#39; (and even a &#39;primary mo=
dule interface unit&#39;!). As far as I understand it, it is almost the sam=
e that old .h files, thus providing no real benefit over the latter when wr=
iting new code.<br><br>So, my question is why was this preambule necessary?=
 Can&#39;t we avoid it?<br>Also there seems to be a paper which=C2=A0 indic=
ate that preambules are unnecessary (http://www.open-std.org/jtc1/sc22/wg21=
/docs/papers/2018/p1299r0.html). What&#39;s the status about this?<br><br>T=
hanks,<br>Masse Nicolas.<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/e3f7a8a5-8e78-49f5-97df-139951f5d07a%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/e3f7a8a5-8e78-49f5-97df-139951f5d07a=
%40isocpp.org</a>.<br />

------=_Part_2101_1163182435.1543353029210--

------=_Part_2100_593798603.1543353029210--

.

On Tue, 27 Nov 2018 at 22:10, <masse.nicolas@gmail.com> wrote:
> The way modules have been done, they require the sources files to declare=
 which module they implements and what they exports into a preambule.
> To be honest, I don't really get why this was necessary.

My understanding is that the main reason is that it helps tools know
the dependencies without having to parse the rest of the C++ syntax.
Build systems will have to check every source file in a first pass to
quickly decide what have to be built, by making a dependency graph.
This pass is simple if the information is easily locatable and with
always a strict subset of possible C++ syntax.

(also it's similar to other module system from other languages, but
that's not a reason).

> Moreover, i found some drawbacks with it:
> - It makes sources files dependent on which modules they will be shipped =
in.

I'm not sure I understand this point.
Isn't it the point of modules to associate a module name to sources?

> - Not only the sources does declare the module they belongs to, but they =
also need to be put together in the build system (may it be Makefiles, cmak=
e, ...). This goes against the DRY concept since it cause duplication of in=
formation.

I don't understand where would be a duplicate information. The module
names exist only in sources, not in build system's project description
files (at least in any decent build system).

> - There is a concept of 'module interface unit' (and even a 'primary modu=
le interface unit'!). As far as I understand it, it is almost the same that=
 old .h files, thus providing no real benefit over the latter when writing =
new code.

Of course it provides benefit! It's like saying that a header file and
a module is similar, but it's really not. For example, your header
will leak it's names into user's user's code. Modules will not by
default.
The point of these interface unit is to allow you to not change the
interface but change the implementation without the user aving to
recompile their code, even if all the module code is defined in one
file.

>
> So, my question is why was this preambule necessary? Can't we avoid it?

I'm not an expert, but I believe it is necessary if we want something
that is easy to implement and works well with human readers.

> Also there seems to be a paper which  indicate that preambules are unnece=
ssary (http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p1299r0.html=
). What's the status about this?

This paper will be published very soon, but you can ask the author for
a copy. Here is the revision 3's intro copy/pasted:

---
Module Preamble is Unnecessarily Fragile

Nathan Sidwell

The ATOM proposal introduced the module preamble. The merged document
modified that concept
for increased flexibility. The rules determining the extent of the
preamble have been modified, but it
remains fragile. We should consider making the preamble more robust.
TL;DR: This was presented to EWG at the San Diego=E2=80=9918 meeting. It wa=
s
accepted and is merged to
p1103.

----

As you can see, it's a fix of the preamble, not a removal.

A. Jo=C3=ABl Lamotte

--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/CAOU91OPMe-0PU7zEfKKPSQNMwtaf8cw%2Bq24XAes9pZTJq=
PGrcg%40mail.gmail.com.

.

------=_Part_1098_126005908.1543531243412
Content-Type: multipart/alternative;
 boundary="----=_Part_1099_1279013480.1543531243412"

------=_Part_1099_1279013480.1543531243412
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi,

Le mercredi 28 novembre 2018 12:16:53 UTC+1, Klaim - Jo=C3=ABl Lamotte a =
=C3=A9crit :
>
> On Tue, 27 Nov 2018 at 22:10, <masse....@gmail.com <javascript:>> wrote:=
=20
> > The way modules have been done, they require the sources files to=20
> declare which module they implements and what they exports into a=20
> preambule.=20
> > To be honest, I don't really get why this was necessary.=20
>
> My understanding is that the main reason is that it helps tools know=20
> the dependencies without having to parse the rest of the C++ syntax.=20
> Build systems will have to check every source file in a first pass to=20
> quickly decide what have to be built, by making a dependency graph.=20
> This pass is simple if the information is easily locatable and with=20
> always a strict subset of possible C++ syntax.=20
>
=20
2 things here:
- The dependency graph could be quite hard to compute and will require to=
=20
parse every source files. While this is viable on small projects, this=20
could (and probably will) be a problem on large ones.
- So far, dependency have always been computed from the build system=20
itself, by specify which files are part of a library, and what other=20
libraries are needed to create each one of them.=20
Basically this is the opposite approach where this information is described=
=20
in the build system and is not know by the sources files. And so far, I do=
=20
believe this model works well and doesn't require to be changed.
=20
Also, the way you phrase it seem to indicate we're modifying the language=
=20
to help other tools (not compilers) to deal with it. I hope it's not the=20
case.

(also it's similar to other module system from other languages, but=20
> that's not a reason).=20
>
Agreed, it's not a reason.
=20

>
> > Moreover, i found some drawbacks with it:=20
> > - It makes sources files dependent on which modules they will be shippe=
d=20
> in.=20
>
> I'm not sure I understand this point.=20
> Isn't it the point of modules to associate a module name to sources?

=20
I don't think so.
I think the point here is how to export the functions, global variables,=20
.... in a more efficient way than using header files (eg: by avoiding to=20
parse and reparse the same code every times an header is included).
Note that after reading=20
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4047.pdf, it seems=
=20
they also speaks about "componentization", but i'm usure the current=20
proposal is the best way to achieve it (exporting or not a symbols can for=
=20
example already be specified using the visibility attribute when using=20
clang/gcc).


> > - Not only the sources does declare the module they belongs to, but the=
y=20
> also need to be put together in the build system (may it be Makefiles,=20
> cmake, ...). This goes against the DRY concept since it cause duplication=
=20
> of information.=20
>
> I don't understand where would be a duplicate information. The module=20
> names exist only in sources, not in build system's project description=20
> files (at least in any decent build system).=20
>
> As said above, this is basically the opposite approach. By the way why do=
=20
we need to put your files together in the source code inside a module while=
=20
we already put them inside the same library or executable at the build=20
system level?

> - There is a concept of 'module interface unit' (and even a 'primary=20
> module interface unit'!). As far as I understand it, it is almost the sam=
e=20
> that old .h files, thus providing no real benefit over the latter when=20
> writing new code.=20
>
> Of course it provides benefit! It's like saying that a header file and=20
> a module is similar, but it's really not. For example, your header=20
> will leak it's names into user's user's code. Modules will not by=20
> default.=20
>
The point of these interface unit is to allow you to not change the=20
> interface but change the implementation without the user aving to=20
> recompile their code, even if all the module code is defined in one=20
> file.=20
>
The interface/implementation separation is already there when using header=
=20
files, so what you describe here seems to me already possible.
I'm not sure to get your point here.

=20

>=20
> > So, my question is why was this preambule necessary? Can't we avoid it?=
=20
>
> I'm not an expert, but I believe it is necessary if we want something=20
> that is easy to implement and works well with human readers.=20
>
> > Also there seems to be a paper which  indicate that preambules are=20
> unnecessary (
> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p1299r0.html).=20
> What's the status about this?=20
>
> This paper will be published very soon, but you can ask the author for=20
> a copy. Here is the revision 3's intro copy/pasted:=20
>
> ---=20
> Module Preamble is Unnecessarily Fragile=20
>
> Nathan Sidwell=20
>
> The ATOM proposal introduced the module preamble. The merged document=20
> modified that concept=20
> for increased flexibility. The rules determining the extent of the=20
> preamble have been modified, but it=20
> remains fragile. We should consider making the preamble more robust.=20
> TL;DR: This was presented to EWG at the San Diego=E2=80=9918 meeting. It =
was=20
> accepted and is merged to=20
> p1103.=20
>
> ----=20
>
> As you can see, it's a fix of the preamble, not a removal.=20
>
=20
Yes, unfortunately.


> A. Jo=C3=ABl Lamotte=20
>

Thanks for your answer,
Masse Nicolas.

--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/16989401-2f0d-4200-997e-0ac60b47bec3%40isocpp.or=
g.

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

<div dir=3D"ltr">Hi,<br><br>Le mercredi 28 novembre 2018 12:16:53 UTC+1, Kl=
aim - Jo=C3=ABl Lamotte a =C3=A9crit=C2=A0:<blockquote class=3D"gmail_quote=
" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding=
-left: 1ex;">On Tue, 27 Nov 2018 at 22:10, &lt;<a href=3D"javascript:" targ=
et=3D"_blank" gdf-obfuscated-mailto=3D"TDsxLvRKCAAJ" rel=3D"nofollow" onmou=
sedown=3D"this.href=3D&#39;javascript:&#39;;return true;" onclick=3D"this.h=
ref=3D&#39;javascript:&#39;;return true;">masse....@gmail.com</a>&gt; wrote=
:
<br>&gt; The way modules have been done, they require the sources files to =
declare which module they implements and what they exports into a preambule=
..
<br>&gt; To be honest, I don&#39;t really get why this was necessary.
<br>
<br>My understanding is that the main reason is that it helps tools know
<br>the dependencies without having to parse the rest of the C++ syntax.
<br>Build systems will have to check every source file in a first pass to
<br>quickly decide what have to be built, by making a dependency graph.
<br>This pass is simple if the information is easily locatable and with
<br>always a strict subset of possible C++ syntax. <br></blockquote><div>=
=C2=A0</div><div>2 things here:</div><div>- The dependency graph could be q=
uite hard to compute and will require to parse every source files. While th=
is is viable on small projects, this could (and probably will) be a problem=
 on large ones.</div><div>- So far, dependency have always been computed fr=
om the build system itself, by specify which files are part of a library, a=
nd what other libraries are needed to create each one of them. <br></div><d=
iv>Basically this is the opposite approach where this information is descri=
bed in the build system and is not know by the sources files. And so far, I=
 do believe this model works well and doesn&#39;t require to be changed.<br=
></div><div>=C2=A0</div><div><div>Also, the way you phrase it seem to indic=
ate we&#39;re modifying the language to help other tools (not compilers) to=
 deal with it. I hope it&#39;s not the case.</div><div><br></div></div><blo=
ckquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-=
left: 1px #ccc solid;padding-left: 1ex;">(also it&#39;s similar to other mo=
dule system from other languages, but
<br>that&#39;s not a reason).
<br></blockquote><div>Agreed, it&#39;s not a reason.<br></div><div>=C2=A0</=
div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex=
;border-left: 1px #ccc solid;padding-left: 1ex;">
<br>&gt; Moreover, i found some drawbacks with it:
<br>&gt; - It makes sources files dependent on which modules they will be s=
hipped in.
<br>
<br>I&#39;m not sure I understand this point.
<br>Isn&#39;t it the point of modules to associate a module name to sources=
?</blockquote><div>=C2=A0</div><div>I don&#39;t think so.<br></div><div>I t=
hink the point here is how to export the functions, global variables, ... i=
n a more efficient way than using header files (eg: by avoiding to parse an=
d reparse the same code every times an header is included).<br></div><div>N=
ote that after reading http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2=
014/n4047.pdf, it seems they also speaks about &quot;componentization&quot;=
, but i&#39;m usure the current proposal is the best way to achieve it (exp=
orting or not a symbols can for example already be specified using the visi=
bility attribute when using clang/gcc).<br></div><div><br></div><blockquote=
 class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1=
px #ccc solid;padding-left: 1ex;">
<br>&gt; - Not only the sources does declare the module they belongs to, bu=
t they also need to be put together in the build system (may it be Makefile=
s, cmake, ...). This goes against the DRY concept since it cause duplicatio=
n of information.
<br>
<br>I don&#39;t understand where would be a duplicate information. The modu=
le
<br>names exist only in sources, not in build system&#39;s project descript=
ion
<br>files (at least in any decent build system).
<br>
<br></blockquote><div>As said above, this is basically the opposite approac=
h. By the way why do we need to put your files together in the source code =
inside a module while we already put them inside the same library or execut=
able at the build system level?<br></div><div> <br></div><blockquote class=
=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #cc=
c solid;padding-left: 1ex;">&gt; - There is a concept of &#39;module interf=
ace unit&#39; (and even a &#39;primary module interface unit&#39;!). As far=
 as I understand it, it is almost the same that old .h files, thus providin=
g no real benefit over the latter when writing new code.
<br>
<br>Of course it provides benefit! It&#39;s like saying that a header file =
and
<br>a module is similar, but it&#39;s really not. For example, your header
<br>will leak it&#39;s names into user&#39;s user&#39;s code. Modules will =
not by
<br>default.
<br></blockquote><blockquote class=3D"gmail_quote" style=3D"margin: 0;margi=
n-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">The point of =
these interface unit is to allow you to not change the
<br>interface but change the implementation without the user aving to
<br>recompile their code, even if all the module code is defined in one
<br>file.
<br></blockquote><div>The interface/implementation separation is already th=
ere when using header files, so what you describe here seems to me already =
possible.</div><div>I&#39;m not sure to get your point here.</div><div><br>=
</div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8=
ex;border-left: 1px #ccc solid;padding-left: 1ex;">
=C2=A0</blockquote><blockquote class=3D"gmail_quote" style=3D"margin: 0;mar=
gin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">&gt;
<br>&gt; So, my question is why was this preambule necessary? Can&#39;t we =
avoid it?
<br>
<br>I&#39;m not an expert, but I believe it is necessary if we want somethi=
ng
<br>that is easy to implement and works well with human readers.
<br>
<br>&gt; Also there seems to be a paper which =C2=A0indicate that preambule=
s are unnecessary (<a href=3D"http://www.open-std.org/jtc1/sc22/wg21/docs/p=
apers/2018/p1299r0.html" target=3D"_blank" rel=3D"nofollow" onmousedown=3D"=
this.href=3D&#39;http://www.google.com/url?q\x3dhttp%3A%2F%2Fwww.open-std.o=
rg%2Fjtc1%2Fsc22%2Fwg21%2Fdocs%2Fpapers%2F2018%2Fp1299r0.html\x26sa\x3dD\x2=
6sntz\x3d1\x26usg\x3dAFQjCNGS_lNR8sc5lAuL4MYIoMN-2n3-9g&#39;;return true;" =
onclick=3D"this.href=3D&#39;http://www.google.com/url?q\x3dhttp%3A%2F%2Fwww=
..open-std.org%2Fjtc1%2Fsc22%2Fwg21%2Fdocs%2Fpapers%2F2018%2Fp1299r0.html\x2=
6sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNGS_lNR8sc5lAuL4MYIoMN-2n3-9g&#39;;ret=
urn true;">http://www.open-std.org/jtc1/<wbr>sc22/wg21/docs/papers/2018/<wb=
r>p1299r0.html</a>). What&#39;s the status about this?
<br>
<br>This paper will be published very soon, but you can ask the author for
<br>a copy. Here is the revision 3&#39;s intro copy/pasted:
<br>
<br>---
<br>Module Preamble is Unnecessarily Fragile
<br>
<br>Nathan Sidwell
<br>
<br>The ATOM proposal introduced the module preamble. The merged document
<br>modified that concept
<br>for increased flexibility. The rules determining the extent of the
<br>preamble have been modified, but it
<br>remains fragile. We should consider making the preamble more robust.
<br>TL;DR: This was presented to EWG at the San Diego=E2=80=9918 meeting. I=
t was
<br>accepted and is merged to
<br>p1103.
<br>
<br>----
<br>
<br>As you can see, it&#39;s a fix of the preamble, not a removal.
<br></blockquote><div>=C2=A0</div><div>Yes, unfortunately.</div><div><br></=
div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex=
;border-left: 1px #ccc solid;padding-left: 1ex;">
<br>A. Jo=C3=ABl Lamotte
<br></blockquote><div><br></div><div>Thanks for your answer,</div><div>Mass=
e Nicolas.<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/16989401-2f0d-4200-997e-0ac60b47bec3%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/16989401-2f0d-4200-997e-0ac60b47bec3=
%40isocpp.org</a>.<br />

------=_Part_1099_1279013480.1543531243412--

------=_Part_1098_126005908.1543531243412--

.

On Thu, 29 Nov 2018 at 23:40, masse.nicolas@gmail.com
<masse.nicolas@gmail.com> wrote:
>
> Hi,
>
> Le mercredi 28 novembre 2018 12:16:53 UTC+1, Klaim - Jo=C3=ABl Lamotte a =
=C3=A9crit :
>>
>> On Tue, 27 Nov 2018 at 22:10, <masse....@gmail.com> wrote:
>> > The way modules have been done, they require the sources files to decl=
are which module they implements and what they exports into a preambule.
>> > To be honest, I don't really get why this was necessary.
>>
>> My understanding is that the main reason is that it helps tools know
>> the dependencies without having to parse the rest of the C++ syntax.
>> Build systems will have to check every source file in a first pass to
>> quickly decide what have to be built, by making a dependency graph.
>> This pass is simple if the information is easily locatable and with
>> always a strict subset of possible C++ syntax.
>
>
> 2 things here:
> - The dependency graph could be quite hard to compute and will require to=
 parse every source files. While this is viable on small projects, this cou=
ld (and probably will) be a problem on large ones.

So far build2's main author reports no problem with this, as long as
the preamble is easilly parsable without having to have a complete C++
parser.
Also it seems to help making the rest of the compilation process faster.

I have some hello world using modules if you want to try them as a
starting point for converting a library and see if you see
improvements?

> - So far, dependency have always been computed from the build system itse=
lf, by specify which files are part of a library, and what other libraries =
are needed to create each one of them.

That part do not change as module have nothing to do with the
dependency graph at the link level.

> Basically this is the opposite approach where this information is describ=
ed in the build system and is not know by the sources files. And so far, I =
do believe this model works well and doesn't require to be changed.

I think you're mixing the end result programs (exes, dlls/so, static
libraries) with modules. A C++ language module have nothing to do with
the actual generated binaries. It's code compartmentalization mainly.
You can have 10 modules in one so or in one exe, or in a
module-interface-only library (like a header-only library).

> Also, the way you phrase it seem to indicate we're modifying the language=
 to help other tools (not compilers) to deal with it. I hope it's not the c=
ase.

Modules add to the language, it doesn't "modify" the current one.
Tools are handicapped by the current include system.
Why would it be not the case? How do you want something like an IDE
extension trying to deduce where the words in the line you're pointing
to are from? They need to know the dependencies of the context.
Also the main tool that this helps is build systems, that can then
easily expose the dependency graph (of modules, not of binaries, which
they already do).

>>
>> > Moreover, i found some drawbacks with it:
>> > - It makes sources files dependent on which modules they will be shipp=
ed in.
>>
>> I'm not sure I understand this point.
>> Isn't it the point of modules to associate a module name to sources?
>
>
> I don't think so.
> I think the point here is how to export the functions, global variables, =
.... in a more efficient way than using header files (eg: by avoiding to par=
se and reparse the same code every times an header is included).

Here in the context of modules, "export" means "making these names
visible to the importer", it does not mean something like dllexport.
Just clarifying because the way you point this is weird to me, in this cont=
ext.

Other than that I agree with you and it seems to do exactly that:
modules are compiled once. The preamble pre-reading to build the
modules dependency graph is trivial compared to what is needed to
parse the language for compilation.

> Note that after reading http://www.open-std.org/jtc1/sc22/wg21/docs/paper=
s/2014/n4047.pdf, it seems they also speaks about "componentization", but i=
'm usure the current proposal is the best way to achieve it (exporting or n=
ot a symbols can for example already be specified using the visibility attr=
ibute when using clang/gcc).
>

Modules do nothing to symbols. They componentize names.
If you want to export symbols, as in making a function in a .so/,dll
usable by another program, you stil have to add some dllexport/import
macros as it have nothing to do with modules.
I have an example here where I use some import/export macro
(symexport) in addition to a module export:
https://github.com/Klaim/build2-libhelloworld-exe-modularized/blob/master/l=
ibhelloworld-modules/helloworld-modules.mxx
(The syntax is the one implemented in VS 15.9 so it's Modules TS
syntax, not more recent Module proposal version).

Note that there is another proposal for a library API for helping with
plugins. But again this have nothing to do with modules.

>>
>> > - Not only the sources does declare the module they belongs to, but th=
ey also need to be put together in the build system (may it be Makefiles, c=
make, ...). This goes against the DRY concept since it cause duplication of=
 information.
>>
>> I don't understand where would be a duplicate information. The module
>> names exist only in sources, not in build system's project description
>> files (at least in any decent build system).
>>
> As said above, this is basically the opposite approach.

Again I think you're mixing binaries dependencies and modules (as in
code-only) dependencies.

> By the way why do we need to put your files together in the source code i=
nside a module while we already put them inside the same library or executa=
ble at the build system level?

The basic idea is that it depends on how you like to organize your
code. Modules are designed to not get in your way with this.
So if you want to have all the code in one module file (which then is
the module interface, with a public eported part, and maybe another
part not exported), nothing prevent you to do so.
If you want to splitt 1 Module into say 10 source files, you have
different ways to do so. The main thing is that at the end there is
only one file that defines what the module exports.
If you want to splitt your module in several modules then make one of
the module export the others, you can also to that.
If you want to have only the module interface containing exported
names, and all the other source module files having the definitions,
you can.
Etc. Organize as you want, the only constraint is that for one module,
there needs to be one file that will export the names for importers.
The details of how to do these is longer to explain but I think
several talks and papers can help with that.

Again, this have nothing to do with the binary linking part of the
process of building programs, so you can have 10 modules in a .so or
in a exe if you want.

>> > - There is a concept of 'module interface unit' (and even a 'primary m=
odule interface unit'!). As far as I understand it, it is almost the same t=
hat old .h files, thus providing no real benefit over the latter when writi=
ng new code.
>>
>> Of course it provides benefit! It's like saying that a header file and
>> a module is similar, but it's really not. For example, your header
>> will leak it's names into user's user's code. Modules will not by
>> default.
>>
>> The point of these interface unit is to allow you to not change the
>> interface but change the implementation without the user aving to
>> recompile their code, even if all the module code is defined in one
>> file.
>
> The interface/implementation separation is already there when using heade=
r files, so what you describe here seems to me already possible.
> I'm not sure to get your point here.
>

Ok, to clarify: it's kind of the same idea but done in a different way
which removes the issues with headers.
Among numerous issues, headers (assuming with only interfaces exposed
in them), cannot guarantee independence of what they expose.

    #include "aaa.hpp"  // void foo(Bar b);
    #include "bbb.hpp"  // #define Bar Kikoo

Can give a different code than

   #include "bbb.hpp" // #define Bar Kikoo
   #include "aaa.hpp" // void foo(Bar b);

Here both headers interract because in the end their content only
exist in the cpp including, so they impact each other.
You can try to make sure that your headers will always produce
equivalent code whatever the the other includes around (we call these
"well behaved" and there is a proposed mechanism
to help use them as if they were modules), but you are still dependent
on them and external ones because just one header could redefine any
word used in the following header included (mainly through macros).

With modules:

import aaa;
import bbb;

and

import bbb;
import aaa;

Are stictly equivalent, by design, whatever is define in these
modules. Importing one will not change the other as macros are simply
not imported, and only names/signatures can be exported.
Because this is only importing names from these modules in the set of
possible names that could be found when you try to use a name.

But you are right that in essence the module interface solve the same
problem (better) than having headers with only interfaces
declarations/definitions.

>> As you can see, it's a fix of the preamble, not a removal.
> Yes, unfortunately.

I'm not sure what is the problem with the preamble exactly? Did you
want to import from another place?

>
>
> Thanks for your answer,

No problem. :)

Jo=C3=ABl

--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/CAOU91ONR5v9ujCaM5Riu5Dc39cejV4VcMEdieF3O6b_edy%=
2BY7g%40mail.gmail.com.

.

------=_Part_12_1062633911.1544035619133
Content-Type: multipart/alternative;
 boundary="----=_Part_13_470747068.1544035619133"

------=_Part_13_470747068.1544035619133
Content-Type: text/plain; charset="UTF-8"

After reading your answer and thinking about it in the last days, I thing I
understand things a bit better now.
First I understand that module are far less related to the linking problem
than I first tough.
Also, I think I better understand how they will actually work in real world
application.

Still, one question remains for me:
If for example you wanna ship a library.
As of today, you generally with the library the headers so that people
using the library will be able to compile their code and make use of the
library you made.
But how does it work if you wanna use modules? do you ship a module file
together with the lib? And if so, how do you intend to generate this module
file?

Also note that even if I better understand the proposal now, my doubts
about it and the need of declaring the module explicitly remains.
In fact, I would have prefer an approach where the exported symbols are
deduced from the code instead of having to declare it explicitly.

Masse Nicolas.

--
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/a8310d69-20cb-48ba-8a8e-c62c09d4cd94%40isocpp.org.

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

<div dir=3D"ltr"><div>After reading your answer and thinking about it in th=
e last days, I thing I understand things a bit better now.</div><div>First =
I understand that module are far less related to the linking problem than I=
 first tough.</div><div>Also, I think I better understand how they will act=
ually work in real world application.</div><div><br></div><div>Still, one q=
uestion remains for me:</div><div>If for example you wanna ship a library.<=
/div><div>As of today, you generally with the library the headers so that p=
eople using the library will be able to compile their code and make use of =
the library you made.</div><div>But how does it work if you wanna use modul=
es? do you ship a module file together with the lib? And if so, how do you =
intend to generate this module file?<br></div><div><br></div><div>Also note=
 that even if I better understand the proposal now, my doubts about it and =
the need of declaring the module explicitly remains.</div><div>In fact, I w=
ould have prefer an approach where the exported symbols are deduced from th=
e code instead of having to declare it explicitly.</div><div></div><div><br=
></div><div>Masse Nicolas.<br></div><div><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/a8310d69-20cb-48ba-8a8e-c62c09d4cd94%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/a8310d69-20cb-48ba-8a8e-c62c09d4cd94=
%40isocpp.org</a>.<br />

------=_Part_13_470747068.1544035619133--

------=_Part_12_1062633911.1544035619133--

.

On Wed, 5 Dec 2018 at 20:47, <masse.nicolas@gmail.com> wrote:
>
> After reading your answer and thinking about it in the last days, I thing I understand things a bit better now.
> First I understand that module are far less related to the linking problem than I first tough.
> Also, I think I better understand how they will actually work in real world application.
>
> Still, one question remains for me:
> If for example you wanna ship a library.
> As of today, you generally with the library the headers so that people using the library will be able to compile their code and make use of the library you made.
> But how does it work if you wanna use modules? do you ship a module file together with the lib? And if so, how do you intend to generate this module file?

Yes, you ship the module interface with your lib. You compile the
module for the target implementation you want to support.

> Also note that even if I better understand the proposal now, my doubts about it and the need of declaring the module explicitly remains.
> In fact, I would have prefer an approach where the exported symbols are deduced from the code instead of having to declare it explicitly.

Deduced how? The problem we have today with headers is that everything
in a header needs to be parsed, whether part of the actual
interface of the library or not. Modules give us control over what
things are part of the interface and what things are not.

--
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/CAFk2RUaoP3h62RX10FfFv3ttyt1he96KJ_R_m%3DM7UA8%3Dbf0O3A%40mail.gmail.com.

.

On 12/5/18 2:01 PM, Ville Voutilainen wrote:
> On Wed, 5 Dec 2018 at 20:47, <masse.nicolas@gmail.com> wrote:
>> After reading your answer and thinking about it in the last days, I thing I understand things a bit better now.
>> First I understand that module are far less related to the linking problem than I first tough.
>> Also, I think I better understand how they will actually work in real world application.
>>
>> Still, one question remains for me:
>> If for example you wanna ship a library.
>> As of today, you generally with the library the headers so that people using the library will be able to compile their code and make use of the library you made.
>> But how does it work if you wanna use modules? do you ship a module file together with the lib? And if so, how do you intend to generate this module file?
> Yes, you ship the module interface with your lib. You compile the
> module for the target implementation you want to support.

To be clear, I believe Ville means that you ship the module interface
unit source code (not a binary module artifact as they are not portable)
and you link any object files produced by compiling the module interface
unit in your compiled library for your supported platforms.

Tom.

>
>> Also note that even if I better understand the proposal now, my doubts about it and the need of declaring the module explicitly remains.
>> In fact, I would have prefer an approach where the exported symbols are deduced from the code instead of having to declare it explicitly.
> Deduced how? The problem we have today with headers is that everything
> in a header needs to be parsed, whether part of the actual
> interface of the library or not. Modules give us control over what
> things are part of the interface and what things are not.
>

--
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/08290107-c63b-3ef6-09d4-16c7b6c495ab%40honermann.net.

.

Adding to Ville's comments:
On Wed, 5 Dec 2018 at 19:47, <masse.nicolas@gmail.com> wrote:
> Still, one question remains for me:
> If for example you wanna ship a library.
> As of today, you generally with the library the headers so that people us=
ing the library will be able to compile their code and make use of the libr=
ary you made.

You are focusing specifically on the shared-library case, ok. Just
note that it's not always the best solution for all libraries or
users.

> But how does it work if you wanna use modules? do you ship a module file =
together with the lib? And if so, how do you intend to generate this module=
 file?

Just ship a module interface unit that only contain the exported names
marked, if implemented separately, as exported/imported symbols too.
That's where it's interesting to have a module interface unit only
contain the exported names+symbols.

///////////////////////////////////////////////////////////////////////////=
/
//// Module interface: mymodule.mxx

export module mymodule;

// MYMODULE_API does the export/import dance, or look at build2's
__symexport as another way to do this.

export namespace mymodule { // export all the names in this namespace scope

    class Kikoo; // Name exported but not symbol import/export: we
don't want the user to use it's interface, just see it's name because
it's used in other interfaces

    MYMODULE_API Kikoo& foo();  // name exported but also symbol import/exp=
ort
    MYMODULE_API void bar(Kikoo&);  // name exported but also symbol
import/export


    template<class T>
    struct Lol { ... }; // Template, so no need to export symbols, it
might benefit from less compile time for the user though.

}

//////////////////////////////////////////////////
////// Module implementation : mymodule.cpp
module mymodule:impl; // If I remember correctly, that's a module
partition, not sure about the syntax

// Just implement everything here.
namespace mymodule{
   class Kikoo { ... };

   Kikoo& foo() { ... }
   void bar(Kikoo&) { ... }

}

//////////////////////////////////////////////////////

I'm not sure of the exact syntax so bear with me, but basically once
you build that in a shared library, you just have to provide
mymodule.mxx to the user, with the shared library binary (and maybe a
..lib on Windows).
You can try that in the library example using build2+msvc I linked to,
just move the implementation in a separate module file with the same
module name but not exporting.
The test is setup to link with the library, shared mode by default, so
if the test work, it correctly only used the module interface and
linked to it.

> Also note that even if I better understand the proposal now, my doubts ab=
out it and the need of declaring the module explicitly remains.

No problem with that, we can probably help clarifying or maybe you can
find a pain point before it gets standardized.

> In fact, I would have prefer an approach where the exported symbols are d=
educed from the code instead of having to declare it explicitly.

As pointed before, modules aren't related with linking. Though once
they are available, we will finally have a clearer way to specify in
C++ the boundaries of a library.
With this, it might be possible later to help with the symbol
export/import, but that seems complicated as it imply specifying some
stuffs that are currently unspecified.

A. Jo=C3=ABl Lamotte

--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/CAOU91OOsk6-3cHUYiFA7UGtcNrpjbNdSROQ3PqeAJW%3DH0=
6rgYA%40mail.gmail.com.

.

On Wed, 5 Dec 2018 at 23:43, Tom Honermann <tom@honermann.net> wrote:
>
> On 12/5/18 2:01 PM, Ville Voutilainen wrote:
> > On Wed, 5 Dec 2018 at 20:47, <masse.nicolas@gmail.com> wrote:
> >> After reading your answer and thinking about it in the last days, I thing I understand things a bit better now.
> >> First I understand that module are far less related to the linking problem than I first tough.
> >> Also, I think I better understand how they will actually work in real world application.
> >>
> >> Still, one question remains for me:
> >> If for example you wanna ship a library.
> >> As of today, you generally with the library the headers so that people using the library will be able to compile their code and make use of the library you made.
> >> But how does it work if you wanna use modules? do you ship a module file together with the lib? And if so, how do you intend to generate this module file?
> > Yes, you ship the module interface with your lib. You compile the
> > module for the target implementation you want to support.
>
> To be clear, I believe Ville means that you ship the module interface
> unit source code (not a binary module artifact as they are not portable)
> and you link any object files produced by compiling the module interface
> unit in your compiled library for your supported platforms.


I think I mean that you have the choice of shipping 0-N module
interface artifacts and/or the source code.
Good catch, though, Tom. However, I think the "you compile the module
for the target implementation you
want to support" is 60% correct. (Yeah, I pulled that 60% number out
of my sleeve, it doesn't really mean anything).
For the remaining 40% (the number is, again, completely artificial),
you might want to ship something else, for example the source 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/CAFk2RUax%2Bi_chjCLEfb7HGitaOtdMSmSmoot4ZTybT_58%3D4VTQ%40mail.gmail.com.

.

On 12/5/18 5:04 PM, Ville Voutilainen wrote:
> On Wed, 5 Dec 2018 at 23:43, Tom Honermann <tom@honermann.net> wrote:
>> On 12/5/18 2:01 PM, Ville Voutilainen wrote:
>>> On Wed, 5 Dec 2018 at 20:47, <masse.nicolas@gmail.com> wrote:
>>>> After reading your answer and thinking about it in the last days, I th=
ing I understand things a bit better now.
>>>> First I understand that module are far less related to the linking pro=
blem than I first tough.
>>>> Also, I think I better understand how they will actually work in real =
world application.
>>>>
>>>> Still, one question remains for me:
>>>> If for example you wanna ship a library.
>>>> As of today, you generally with the library the headers so that people=
 using the library will be able to compile their code and make use of the l=
ibrary you made.
>>>> But how does it work if you wanna use modules? do you ship a module fi=
le together with the lib? And if so, how do you intend to generate this mod=
ule file?
>>> Yes, you ship the module interface with your lib. You compile the
>>> module for the target implementation you want to support.
>> To be clear, I believe Ville means that you ship the module interface
>> unit source code (not a binary module artifact as they are not portable)
>> and you link any object files produced by compiling the module interface
>> unit in your compiled library for your supported platforms.
>
> I think I mean that you have the choice of shipping 0-N module
> interface artifacts and/or the source code.

Hmm, Gaby has stated many times that .ifc files are not intended for=20
distribution.=C2=A0 Clang, from what I understand, is not promising=20
compatibility for module artifacts across major releases (which makes=20
compatibility across Xcode and LLVM Clang questionable). Gcc currently=20
ties the module artifact to the svn revision.=C2=A0 I am very much under th=
e=20
impression that shipping module artifacts (without the corresponding=20
module interface unit source) will not be a viable choice in practice=20
(at least, not for anyone other than compiler implementors).

> Good catch, though, Tom. However, I think the "you compile the module
> for the target implementation you
> want to support" is 60% correct. (Yeah, I pulled that 60% number out
> of my sleeve, it doesn't really mean anything).
> For the remaining 40% (the number is, again, completely artificial),
> you might want to ship something else, for example the source code.

I meant that, if you are shipping a pre-built library, then the portions=20
of the module interface unit that are not "interface" (e.g.,=20
non-template function definitions) probably need to be pre-compiled and=20
linked into the distributed library (which may have its own dependencies=20
on them) unless the expectation is that the recipient link objects=20
produced by compilation of module interface units into their respective=20
binaries (which seems to me a good recipe for ending up with duplicate=20
definition errors at link time).=C2=A0 I'm very curious to see how build=20
systems are going to end up managing this.

Tom.

--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/0727d34e-0bad-3689-e315-2136bb359e65%40honermann=
..net.

.

------=_Part_335_1436049172.1544096286360
Content-Type: multipart/alternative;
 boundary="----=_Part_336_1904009052.1544096286361"

------=_Part_336_1904009052.1544096286361
Content-Type: text/plain; charset="UTF-8"

On Thursday, December 6, 2018 at 7:05:01 AM UTC+3, Tom Honermann wrote:
>
> Hmm, Gaby has stated many times that .ifc files are not intended for
> distribution.
>

Really? So what such modules are supposed to be? Yet another reincarnation
of precompiled headers?

And why gcc and clang developers are trying "to define interoperable
changes" (see https://gcc.gnu.org/wiki/cxx-modules) and establish stable
ABI
(https://gcc.gnu.org/wiki/cxx-modules?action=AttachFile&do=view&target=module-abi-2017-09-01.pdf)?


--
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/41ef0549-4ff9-4d0d-b033-5eb30055490c%40isocpp.org.

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

<div dir=3D"ltr">On Thursday, December 6, 2018 at 7:05:01 AM UTC+3, Tom Hon=
ermann wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-le=
ft: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">Hmm, Gaby has sta=
ted many times that .ifc files are not intended for=20
<br>distribution.=C2=A0 <br></blockquote><div><br></div><div>Really? So wha=
t such modules are supposed to be? Yet another reincarnation of precompiled=
 headers?</div><div><br></div><div>And why gcc and clang developers are try=
ing &quot;to define interoperable changes&quot; (see https://gcc.gnu.org/wi=
ki/cxx-modules) and establish stable ABI (https://gcc.gnu.org/wiki/cxx-modu=
les?action=3DAttachFile&amp;do=3Dview&amp;target=3Dmodule-abi-2017-09-01.pd=
f)?</div><div><br></div><div><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/41ef0549-4ff9-4d0d-b033-5eb30055490c%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/41ef0549-4ff9-4d0d-b033-5eb30055490c=
%40isocpp.org</a>.<br />

------=_Part_336_1904009052.1544096286361--

------=_Part_335_1436049172.1544096286360--

.

This is a multi-part message in MIME format.
--------------066FFB0FA5943E0A7D6C1194
Content-Type: text/plain; charset="UTF-8"; format=flowed
Content-Transfer-Encoding: quoted-printable

On 12/6/18 6:38 AM, Victor Dyachenko wrote:
> On Thursday, December 6, 2018 at 7:05:01 AM UTC+3, Tom Honermann wrote:
>
>     Hmm, Gaby has stated many times that .ifc files are not intended for
>     distribution.
>
>
> Really? So what such modules are supposed to be? Yet another=20
> reincarnation of precompiled headers?

I think of them as being very much like precompiled headers with a few=20
additions:

 1. Entities that can't be defined in headers without leading to
    duplicate definition problems (e.g., non-template function
    definitions) can be present in module interface units. Compilation
    of the module interface unit emits such entities to a separate
    object file (that must be linked in somewhere).
 2. Macro containment.
 3. Protection against order of include/import problems.
 4. Protection against name collisions.

>
> And why gcc and clang developers are trying "to define interoperable=20
> changes" (see https://gcc.gnu.org/wiki/cxx-modules) and establish=20
> stable ABI=20
> (https://gcc.gnu.org/wiki/cxx-modules?action=3DAttachFile&do=3Dview&targe=
t=3Dmodule-abi-2017-09-01.pdf)?

The changes referred to in those links concern ABI (primarily name=20
mangling), not portability of module artifacts.=C2=A0 The intent of the ABI=
=20
compatibility is to enable objects/libraries compiled with different=20
compilers to be able to be linked together in a single program.=C2=A0 Such=
=20
compatibility does not extend to module artifacts used at compile-time.

Here is a quote from the second link:

"It is taken as axiomatic that the BMI is generated by the same compiler=20
that compiles any TUs
importing the module. As such, it can conspire to step outside the ABI,=20
where such behavior could not
be observed by other TUs."

I believe that should be read as "by the same installation of the=20
compiler" or, minimally, the same version.

Tom.

--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/da76c6e9-93a2-262f-f5dd-e104140dd13a%40honermann=
..net.

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

<html>
  <head>
    <meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3DUTF-8=
">
  </head>
  <body bgcolor=3D"#FFFFFF" text=3D"#000000">
    <div class=3D"moz-cite-prefix">On 12/6/18 6:38 AM, Victor Dyachenko
      wrote:<br>
    </div>
    <blockquote type=3D"cite"
      cite=3D"mid:41ef0549-4ff9-4d0d-b033-5eb30055490c@isocpp.org">
      <meta http-equiv=3D"content-type" content=3D"text/html; charset=3DUTF=
-8">
      <div dir=3D"ltr">On Thursday, December 6, 2018 at 7:05:01 AM UTC+3,
        Tom Honermann wrote:
        <blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left:
          0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">Hmm,
          Gaby has stated many times that .ifc files are not intended
          for <br>
          distribution.=C2=A0 <br>
        </blockquote>
        <div><br>
        </div>
        <div>Really? So what such modules are supposed to be? Yet
          another reincarnation of precompiled headers?</div>
      </div>
    </blockquote>
    <p>I think of them as being very much like precompiled headers with
      a few additions:</p>
    <ol>
      <li>Entities that can't be defined in headers without leading to
        duplicate definition problems (e.g., non-template function
        definitions) can be present in module interface units.=C2=A0
        Compilation of the module interface unit emits such entities to
        a separate object file (that must be linked in somewhere).</li>
      <li>Macro containment.</li>
      <li>Protection against order of include/import problems.</li>
      <li>Protection against name collisions.<br>
      </li>
    </ol>
    <blockquote type=3D"cite"
      cite=3D"mid:41ef0549-4ff9-4d0d-b033-5eb30055490c@isocpp.org">
      <div dir=3D"ltr">
        <div><br>
        </div>
        <div>And why gcc and clang developers are trying "to define
          interoperable changes" (see
          <a class=3D"moz-txt-link-freetext" href=3D"https://gcc.gnu.org/wi=
ki/cxx-modules">https://gcc.gnu.org/wiki/cxx-modules</a>) and establish sta=
ble ABI
(<a class=3D"moz-txt-link-freetext" href=3D"https://gcc.gnu.org/wiki/cxx-mo=
dules?action=3DAttachFile&amp;do=3Dview&amp;target=3Dmodule-abi-2017-09-01.=
pdf">https://gcc.gnu.org/wiki/cxx-modules?action=3DAttachFile&amp;do=3Dview=
&amp;target=3Dmodule-abi-2017-09-01.pdf</a>)?</div>
      </div>
    </blockquote>
    <p>The changes referred to in those links concern ABI (primarily
      name mangling), not portability of module artifacts.=C2=A0 The intent
      of the ABI compatibility is to enable objects/libraries compiled
      with different compilers to be able to be linked together in a
      single program.=C2=A0 Such compatibility does not extend to module
      artifacts used at compile-time.<br>
    </p>
    <p>Here is a quote from the second link:</p>
    <p>"It is taken as axiomatic that the BMI is generated by the same
      compiler that compiles any TUs <br>
      importing the module. As such, it can conspire to step outside the
      ABI, where such behavior could not <br>
      be observed by other TUs."</p>
    <p>I believe that should be read as "by the same installation of the
      compiler" or, minimally, the same version.<br>
    </p>
    <p>Tom.<br>
    </p>
  </body>
</html>

<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/da76c6e9-93a2-262f-f5dd-e104140dd13a%=
40honermann.net?utm_medium=3Demail&utm_source=3Dfooter">https://groups.goog=
le.com/a/isocpp.org/d/msgid/std-proposals/da76c6e9-93a2-262f-f5dd-e104140dd=
13a%40honermann.net</a>.<br />

--------------066FFB0FA5943E0A7D6C1194--

.

------=_Part_729_200322485.1544162224073
Content-Type: multipart/alternative;
 boundary="----=_Part_730_104171009.1544162224073"

------=_Part_730_104171009.1544162224073
Content-Type: text/plain; charset="UTF-8"

IIRC initially modules were based on some sort of high-level C++ AST
representation - XPR
(https://parasol.tamu.edu/pivot/publications/user-guide.pdf). I'm talking
about Gaby's/VC++ implementation. Do they use different approach now? A
there any people here aware of gcc/clang approach? And if XPR is enough to
represent modules interface files (is it?), can't it be standardized at
least in theory?

--
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/36e9388e-9b8d-4c93-9a0a-bedfb00c135f%40isocpp.org.

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

<div dir=3D"ltr">IIRC initially modules were based on some sort of high-lev=
el C++ AST representation - XPR (https://parasol.tamu.edu/pivot/publication=
s/user-guide.pdf). I&#39;m talking about Gaby&#39;s/VC++ implementation. Do=
 they use different approach now? A there any people here aware of gcc/clan=
g approach? And if XPR is enough to represent modules interface files (is i=
t?), can&#39;t it be standardized at least in theory?<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/36e9388e-9b8d-4c93-9a0a-bedfb00c135f%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/36e9388e-9b8d-4c93-9a0a-bedfb00c135f=
%40isocpp.org</a>.<br />

------=_Part_730_104171009.1544162224073--

------=_Part_729_200322485.1544162224073--

.

On 12/7/18 12:57 AM, Victor Dyachenko wrote:
> IIRC initially modules were based on some sort of high-level C++ AST=20
> representation - XPR=20
> (https://parasol.tamu.edu/pivot/publications/user-guide.pdf). I'm=20
> talking about Gaby's/VC++ implementation. Do they use different=20
> approach now?

My understanding is that Microsoft is (still) using an internal fork of=20
IPR (https://github.com/GabrielDosReis/ipr).

> A there any people here aware of gcc/clang approach?

Clang uses its own AST serialization format.=C2=A0 It is the same format=20
Clang uses for pre-compiled headers, .ast files, and traditional Clang=20
modules.=C2=A0 These files are Clang specific and not historically compatib=
le=20
across Clang versions.

Gcc is also using its own AST serialization format that reflects gcc's=20
internal AST.=C2=A0 Nathan Sidwell discusses this in some of his talks.=C2=
=A0 You=20
might want to watch his talk from this year's GNU Tools Cauldron=20
(https://www.youtube.com/watch?v=3D5CadIjPRZpM).=C2=A0 He talks about AST=
=20
serialization around the 20 minute mark.

> And if XPR is enough to represent modules interface files (is it?),=20
> can't it be standardized at least in theory?

IPR has limitations.=C2=A0 For example, it does not store full source=20
information nor preprocessor information (no column or macro expansion=20
information).=C2=A0 This means consumers can't accurately map imported=20
constructs back to source code (for example, in diagnostics).

In practice, I don't think something can be standardized here, nor do I=20
think it would be beneficial.=C2=A0 There are competing requirements for ho=
w=20
much data to store (different compilers/tools need different=20
information).=C2=A0 A goal of modules is to improve compile times and a=20
common format would impose overhead relative to what can be accomplished=20
with a highly optimized compiler/tool specific format.=C2=A0 Harder questio=
ns=20
involve implementation defined things.=C2=A0 How would compiler intrinsics=
=20
and language extensions be handled?=C2=A0 How would implementation defined=
=20
behavior in general be handled?=C2=A0 (The standard has many cases where=20
implementation defined behavior can impact the AST).=C2=A0 The committee ha=
s=20
discussed this a number of times and my impression is that there is no=20
consensus for a standard format (though the committee has not actually=20
polled this).

I think a more interesting question is, what would a standard format=20
enable you to do that you wouldn't be able to otherwise? Can we enable=20
those goals in another way?=C2=A0 For example, would implementation specifi=
c=20
tools (potentially defacto industry standards like c++filt) that expose=20
information from module artifacts, potentially in some standard format,=20
be helpful?

Tom.

--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/ea2a691d-f8bb-2d5c-86ce-9515b9f1350f%40honermann=
..net.

.

------=_Part_81_1128770004.1544565990604
Content-Type: multipart/alternative;
 boundary="----=_Part_82_2139354162.1544565990604"

------=_Part_82_2139354162.1544565990604
Content-Type: text/plain; charset="UTF-8"



> I meant that, if you are shipping a pre-built library, then the portions
> of the module interface unit that are not "interface" (e.g.,
> non-template function definitions) probably need to be pre-compiled and
> linked into the distributed library (which may have its own dependencies
> on them) unless the expectation is that the recipient link objects
> produced by compilation of module interface units into their respective
> binaries (which seems to me a good recipe for ending up with duplicate
> definition errors at link time).  I'm very curious to see how build
> systems are going to end up managing this.
>

So you have the choice whether you ship the source files or a binary
version of it. OK.

Deduced how?
>

Take this code for example:

//sample.cpp

namespace sample
{

struct event
{
    std::string message;
    std::string details;
    std::string file;
    uint line;
};

class event_printer
{
    using format_fn = std::function<void(std::string& str, const event&
ev)>;
    std::vector<format_fn> m_functions;
public:
    event_printer(const std::string& format);
    std::string format(const event& ev) const
    {
        std::string res;
        for(const auto& fn : m_functions)
            fn(res, ev);
        return res;
    }
};

}

From this code, you can easily say that importing this file will import the
declaration of the 2 structs, the first one being just a POD data type,
while the second will have a ctor from a std::string and also a method
format with the given signature.
Note that in this example, the implementation of the ctor and the format
method could be in the same cpp file but don't require to, since the
declaration of the class is enough.

The problem we have today with headers is that everything
> in a header needs to be parsed, whether part of the actual
> interface of the library or not.
>

The idea here is to parse the file only once and to save the "visible" part
of it in a specific file. The next time this file will be imported, we
could just extract the visible part from the generated file (since the
source file didn't change since the other one was generated), avoiding then
to re-parse the source.

Modules give us control over what
> things are part of the interface and what things are not.
>

Yeah, something in my approach is more or less missing here. More or less I
said? Yes, because in fact this partially already exists. I mean, take this
code for example:

//sample_details.cpp

static void print_message(std::string& msg, const event& ev)
{
    msg.append(ev.message);
}

Here you know that the method print_message won't be exported by the
compiler, and thus non-visible outside of the sample_details.cpp file. Even
if you import this file (which shouldn't be done if we take the logic of my
example into account), this method won't be imported because it is internal
to the sample_details.cpp file.
In fact, this mechanism is inherited from C, meaning that it exists from a
long time. But unfortunately, it use the static keyword, which could have
different meanings when used inside a class. Perhaps deprecating the use of
static in this context and replacing it by something else (say internal for
example) could do the trick.

So i just give you a small example of how I saw things, but there are
probably a lot of related problems which need to be resolved, for example
how template should be handled when using this model. I didn't try to solve
all this since my goal is just to make you understand what I mean by "an
approach where the exported symbols are deduced from the code". Also I
believe that most of the choice made for the module proposal could apply to
this model as well.

Masse Nicolas.

--
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/9f2c63e2-7904-49ea-a2ac-87e80fe78e78%40isocpp.org.

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

<div dir=3D"ltr"><br><blockquote class=3D"gmail_quote" style=3D"margin: 0px=
 0px 0px 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1e=
x;">I meant that, if you are shipping a pre-built library, then the portion=
s=20
<br>of the module interface unit that are not &quot;interface&quot; (e.g.,=
=20
<br>non-template function definitions) probably need to be pre-compiled and=
=20
<br>linked into the distributed library (which may have its own dependencie=
s=20
<br>on them) unless the expectation is that the recipient link objects=20
<br>produced by compilation of module interface units into their respective=
=20
<br>binaries (which seems to me a good recipe for ending up with duplicate=
=20
<br>definition errors at link time).=C2=A0 I&#39;m very curious to see how =
build=20
<br>systems are going to end up managing this.
<br></blockquote><div><br></div><div>So you have the choice whether you shi=
p the source files or a binary version of it. OK.=C2=A0</div><div><br></div=
><blockquote class=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; bord=
er-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"><div>Deduced how=
? <br></div></blockquote><div><br></div><div>Take this code for example:</d=
iv><div><br></div><div>//sample.cpp</div><div><br></div><div>namespace samp=
le</div><div>{</div><div><br></div><div>struct event<br>{<br>=C2=A0=C2=A0=
=C2=A0 std::string message;<br>=C2=A0=C2=A0=C2=A0 std::string details;<br>=
=C2=A0=C2=A0=C2=A0 std::string file;<br>=C2=A0=C2=A0=C2=A0 uint line;<br>};=
</div><div><br></div><div>class event_printer<br>{<br>=C2=A0=C2=A0=C2=A0 us=
ing format_fn =3D std::function&lt;void(std::string&amp; str, const event&a=
mp; ev)&gt;;<br>=C2=A0=C2=A0=C2=A0 std::vector&lt;format_fn&gt; m_functions=
;<br>public:<br>=C2=A0=C2=A0=C2=A0 event_printer(const std::string&amp; for=
mat);<br>=C2=A0=C2=A0=C2=A0 std::string format(const event&amp; ev) const<b=
r>=C2=A0=C2=A0=C2=A0 {<br>=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 std::string=
 res;<br>=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 for(const auto&amp; fn : m_f=
unctions)<br>=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 fn(re=
s, ev);<br>=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 return res;<br>=C2=A0=C2=
=A0=C2=A0 }<br>};</div><div><br></div><div>}</div><div><br></div><div>From =
this code, you can easily say that importing this file will import the decl=
aration of the 2 structs, the first one being just a POD data type, while t=
he second will have a ctor from a std::string and also a method format with=
 the given signature.</div><div>Note that in this example, the implementati=
on of the ctor and the format method could be in the same cpp file but don&=
#39;t require to, since the declaration of the class is enough.<br></div><d=
iv><br></div><blockquote class=3D"gmail_quote" style=3D"margin: 0px 0px 0px=
 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"><div=
>The problem we have today with headers is that everything
<br>in a header needs to be parsed, whether part of the actual
<br>interface of the library or not.</div></blockquote><div><br></div><div>=
The idea here is to parse the file only once and to save the &quot;visible&=
quot; part of it in a specific file. The next time this file will be import=
ed, we could just extract the visible part from the generated file (since t=
he source file didn&#39;t change since the other one was generated), avoidi=
ng then to re-parse the source.</div><div><br></div><blockquote class=3D"gm=
ail_quote" style=3D"margin: 0px 0px 0px 0.8ex; border-left: 1px solid rgb(2=
04, 204, 204); padding-left: 1ex;"><div> Modules give us control over what
<br>things are part of the interface and what things are not.
</div></blockquote><div><br></div><div>Yeah, something in my approach is mo=
re or less missing here. More or less I said? Yes, because in fact this par=
tially already exists. I mean, take this code for example:</div><div><br></=
div><div>//sample_details.cpp</div><div><br></div><div>static void print_me=
ssage(std::string&amp; msg, const event&amp; ev) <br></div><div>{ <br></div=
><div>=C2=A0=C2=A0=C2=A0 msg.append(ev.message);</div><div> }<br></div><div=
><br></div><div>Here you know that the method print_message won&#39;t be ex=
ported by the compiler, and thus non-visible outside of the sample_details.=
cpp file. Even if you import this file (which shouldn&#39;t be done if we t=
ake the logic of my example into account), this method won&#39;t be importe=
d because it is internal to the sample_details.cpp file.</div><div>In fact,=
 this mechanism is inherited from C, meaning that it exists from a long tim=
e. But unfortunately, it use the static keyword, which could have different=
 meanings when used inside a class. Perhaps deprecating the use of static i=
n this context and replacing it by something else (say internal for example=
) could do the trick.<br></div><div><br></div><div>So i just give you a sma=
ll example of how I saw things, but there are probably a lot of related pro=
blems which need to be resolved, for example how template should be handled=
 when using this model. I didn&#39;t try to solve all this since my goal is=
 just to make you understand what I mean by &quot;an approach where the exp=
orted symbols are deduced from the code&quot;. Also I believe that most of =
the choice made for the module proposal could apply to this model as well.<=
br></div><div><br></div><div>Masse Nicolas.<br></div><div><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/9f2c63e2-7904-49ea-a2ac-87e80fe78e78%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/9f2c63e2-7904-49ea-a2ac-87e80fe78e78=
%40isocpp.org</a>.<br />

------=_Part_82_2139354162.1544565990604--

------=_Part_81_1128770004.1544565990604--

.

------=_Part_83_2141504049.1544566350748
Content-Type: multipart/alternative;
 boundary="----=_Part_84_1647047048.1544566350749"

------=_Part_84_1647047048.1544566350749
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

I see no problem with the binary format of the module files being=20
implementation defined.=20
Just my 2 cents :) .

Le vendredi 7 d=C3=A9cembre 2018 16:48:42 UTC+1, Tom Honermann a =C3=A9crit=
 :
>
> On 12/7/18 12:57 AM, Victor Dyachenko wrote:=20
> > IIRC initially modules were based on some sort of high-level C++ AST=20
> > representation - XPR=20
> > (https://parasol.tamu.edu/pivot/publications/user-guide.pdf). I'm=20
> > talking about Gaby's/VC++ implementation. Do they use different=20
> > approach now?=20
>
> My understanding is that Microsoft is (still) using an internal fork of=
=20
> IPR (https://github.com/GabrielDosReis/ipr).=20
>
> > A there any people here aware of gcc/clang approach?=20
>
> Clang uses its own AST serialization format.  It is the same format=20
> Clang uses for pre-compiled headers, .ast files, and traditional Clang=20
> modules.  These files are Clang specific and not historically compatible=
=20
> across Clang versions.=20
>
> Gcc is also using its own AST serialization format that reflects gcc's=20
> internal AST.  Nathan Sidwell discusses this in some of his talks.  You=
=20
> might want to watch his talk from this year's GNU Tools Cauldron=20
> (https://www.youtube.com/watch?v=3D5CadIjPRZpM).  He talks about AST=20
> serialization around the 20 minute mark.=20
>
> > And if XPR is enough to represent modules interface files (is it?),=20
> > can't it be standardized at least in theory?=20
>
> IPR has limitations.  For example, it does not store full source=20
> information nor preprocessor information (no column or macro expansion=20
> information).  This means consumers can't accurately map imported=20
> constructs back to source code (for example, in diagnostics).=20
>
> In practice, I don't think something can be standardized here, nor do I=
=20
> think it would be beneficial.  There are competing requirements for how=
=20
> much data to store (different compilers/tools need different=20
> information).  A goal of modules is to improve compile times and a=20
> common format would impose overhead relative to what can be accomplished=
=20
> with a highly optimized compiler/tool specific format.  Harder questions=
=20
> involve implementation defined things.  How would compiler intrinsics=20
> and language extensions be handled?  How would implementation defined=20
> behavior in general be handled?  (The standard has many cases where=20
> implementation defined behavior can impact the AST).  The committee has=
=20
> discussed this a number of times and my impression is that there is no=20
> consensus for a standard format (though the committee has not actually=20
> polled this).=20
>
> I think a more interesting question is, what would a standard format=20
> enable you to do that you wouldn't be able to otherwise? Can we enable=20
> those goals in another way?  For example, would implementation specific=
=20
> tools (potentially defacto industry standards like c++filt) that expose=
=20
> information from module artifacts, potentially in some standard format,=
=20
> be helpful?=20
>
> Tom.=20
>
>

--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/cc398899-8356-4d7a-a0ae-29fa5cfa17c1%40isocpp.or=
g.

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

<div dir=3D"ltr"><div>I see no problem with the binary format of the module=
 files being implementation defined. <br></div><div>Just my 2 cents :) .<br=
></div><br>Le vendredi 7 d=C3=A9cembre 2018 16:48:42 UTC+1, Tom Honermann a=
 =C3=A9crit=C2=A0:<blockquote class=3D"gmail_quote" style=3D"margin: 0;marg=
in-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On 12/7/18 1=
2:57 AM, Victor Dyachenko wrote:
<br>&gt; IIRC initially modules were based on some sort of high-level C++ A=
ST=20
<br>&gt; representation - XPR=20
<br>&gt; (<a href=3D"https://parasol.tamu.edu/pivot/publications/user-guide=
..pdf" target=3D"_blank" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;ht=
tps://www.google.com/url?q\x3dhttps%3A%2F%2Fparasol.tamu.edu%2Fpivot%2Fpubl=
ications%2Fuser-guide.pdf\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNHC8x4h6jk=
Mult7vt7vtKiW1yXrXg&#39;;return true;" onclick=3D"this.href=3D&#39;https://=
www.google.com/url?q\x3dhttps%3A%2F%2Fparasol.tamu.edu%2Fpivot%2Fpublicatio=
ns%2Fuser-guide.pdf\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNHC8x4h6jkMult7v=
t7vtKiW1yXrXg&#39;;return true;">https://parasol.tamu.edu/<wbr>pivot/public=
ations/user-guide.<wbr>pdf</a>). I&#39;m=20
<br>&gt; talking about Gaby&#39;s/VC++ implementation. Do they use differen=
t=20
<br>&gt; approach now?
<br>
<br>My understanding is that Microsoft is (still) using an internal fork of=
=20
<br>IPR (<a href=3D"https://github.com/GabrielDosReis/ipr" target=3D"_blank=
" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;https://www.google.com/u=
rl?q\x3dhttps%3A%2F%2Fgithub.com%2FGabrielDosReis%2Fipr\x26sa\x3dD\x26sntz\=
x3d1\x26usg\x3dAFQjCNH2xa78X0gj92P-Qn2ah88mJldLYA&#39;;return true;" onclic=
k=3D"this.href=3D&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fgithub.=
com%2FGabrielDosReis%2Fipr\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNH2xa78X0=
gj92P-Qn2ah88mJldLYA&#39;;return true;">https://github.com/<wbr>GabrielDosR=
eis/ipr</a>).
<br>
<br>&gt; A there any people here aware of gcc/clang approach?
<br>
<br>Clang uses its own AST serialization format.=C2=A0 It is the same forma=
t=20
<br>Clang uses for pre-compiled headers, .ast files, and traditional Clang=
=20
<br>modules.=C2=A0 These files are Clang specific and not historically comp=
atible=20
<br>across Clang versions.
<br>
<br>Gcc is also using its own AST serialization format that reflects gcc&#3=
9;s=20
<br>internal AST.=C2=A0 Nathan Sidwell discusses this in some of his talks.=
=C2=A0 You=20
<br>might want to watch his talk from this year&#39;s GNU Tools Cauldron=20
<br>(<a href=3D"https://www.youtube.com/watch?v=3D5CadIjPRZpM" target=3D"_b=
lank" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;https://www.youtube.=
com/watch?v\x3d5CadIjPRZpM&#39;;return true;" onclick=3D"this.href=3D&#39;h=
ttps://www.youtube.com/watch?v\x3d5CadIjPRZpM&#39;;return true;">https://ww=
w.youtube.com/<wbr>watch?v=3D5CadIjPRZpM</a>).=C2=A0 He talks about AST=20
<br>serialization around the 20 minute mark.
<br>
<br>&gt; And if XPR is enough to represent modules interface files (is it?)=
,=20
<br>&gt; can&#39;t it be standardized at least in theory?
<br>
<br>IPR has limitations.=C2=A0 For example, it does not store full source=
=20
<br>information nor preprocessor information (no column or macro expansion=
=20
<br>information).=C2=A0 This means consumers can&#39;t accurately map impor=
ted=20
<br>constructs back to source code (for example, in diagnostics).
<br>
<br>In practice, I don&#39;t think something can be standardized here, nor =
do I=20
<br>think it would be beneficial.=C2=A0 There are competing requirements fo=
r how=20
<br>much data to store (different compilers/tools need different=20
<br>information).=C2=A0 A goal of modules is to improve compile times and a=
=20
<br>common format would impose overhead relative to what can be accomplishe=
d=20
<br>with a highly optimized compiler/tool specific format.=C2=A0 Harder que=
stions=20
<br>involve implementation defined things.=C2=A0 How would compiler intrins=
ics=20
<br>and language extensions be handled?=C2=A0 How would implementation defi=
ned=20
<br>behavior in general be handled?=C2=A0 (The standard has many cases wher=
e=20
<br>implementation defined behavior can impact the AST).=C2=A0 The committe=
e has=20
<br>discussed this a number of times and my impression is that there is no=
=20
<br>consensus for a standard format (though the committee has not actually=
=20
<br>polled this).
<br>
<br>I think a more interesting question is, what would a standard format=20
<br>enable you to do that you wouldn&#39;t be able to otherwise? Can we ena=
ble=20
<br>those goals in another way?=C2=A0 For example, would implementation spe=
cific=20
<br>tools (potentially defacto industry standards like c++filt) that expose=
=20
<br>information from module artifacts, potentially in some standard format,=
=20
<br>be helpful?
<br>
<br>Tom.
<br>
<br></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/cc398899-8356-4d7a-a0ae-29fa5cfa17c1%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/cc398899-8356-4d7a-a0ae-29fa5cfa17c1=
%40isocpp.org</a>.<br />

------=_Part_84_1647047048.1544566350749--

------=_Part_83_2141504049.1544566350748--

.

On Tue, 11 Dec 2018 at 23:06, <masse.nicolas@gmail.com> wrote:

> From this code, you can easily say that importing this file will import t=
he declaration of the 2 structs, the first one being just a POD data type, =
while the second will have a ctor from a std::string and also a method form=
at with the given signature.
> Note that in this example, the implementation of the ctor and the format =
method could be in the same cpp file but don't require to, since the declar=
ation of the class is enough.

I am not sure I understand your point because the code you are giving
as example is not a module nor is it exporting anything.
Let's say that you add the `module blah;` line first, then this is not
exporting anything without you explicitely adding `export` keyword in
front of declarations or forward declarations or definitions.
So I don't understand what you mean exactly.

>> The problem we have today with headers is that everything
>> in a header needs to be parsed, whether part of the actual
>> interface of the library or not.
>
>
> The idea here is to parse the file only once and to save the "visible" pa=
rt of it in a specific file.

Note that the standard don't say it should end up in a file. It's a
representation stored somewhere. It could be a database of
intermediate representation for example.

>  The next time this file will be imported, we could just extract the visi=
ble part from the generated file (since the source file didn't change since=
 the other one was generated), avoiding then to re-parse the source.

Not only that. In non-template cases the code have already been
"compiled" so only it's name and interface are checked when importing.
This means that it's not like having the declaration of such function
(for example) copy pasted where you import, it's more like adding the
name and/or signature of the function to a pool of available names.
There is no syntactic collision possible, compared to headers.

For templates, some optimization might be possible (apparently) but
it's still implicitely inline code so whatever goes. In any way,
importing templates is still "adding names to the pool of available
names".
Or you should think that way anyway.

>> Modules give us control over what
>> things are part of the interface and what things are not.
>
>
> Yeah, something in my approach is more or less missing here. More or less=
 I said? Yes, because in fact this partially already exists. I mean, take t=
his code for example:
>
> //sample_details.cpp
>
> static void print_message(std::string& msg, const event& ev)
> {
>     msg.append(ev.message);
> }
>
> Here you know that the method print_message won't be exported by the comp=
iler, and thus non-visible outside of the sample_details.cpp file. Even if =
you import this file (which shouldn't be done if we take the logic of my ex=
ample into account), this method won't be imported because it is internal t=
o the sample_details.cpp file.
> In fact, this mechanism is inherited from C, meaning that it exists from =
a long time. But unfortunately, it use the static keyword, which could have=
 different meanings when used inside a class. Perhaps deprecating the use o=
f static in this context and replacing it by something else (say internal f=
or example) could do the trick.
>

Here you are describing symbol visibility which is orthogonal to what
modules does, though if you mark a functions static it cannot be
exported through modules (if my memory is correct).
There are big differences. If your static function is part of a
module, then it also mean that other modules can have the same
functioon name in them, even if they end up compiled in the same
binary (ODR is not violated because this function is identified as
owned by the module, so can be differenciated from another function
with same name and same signature and same namespace but ownd by
another module).
Module ownership is unrelated to symbol visibility, but it's maybe
hard to see the nuance.

To be short, let's say this code is in a module. That you put a static
or not in front of it, as long as you didn't export this function,
it's owned by the module and not exported, therefore nobody can
"compile" with it.
If someone does a declaration in their cpp file of such function which
is owned by a separate module, my understanding is that it will end in
a link error as the function in the module and the function declared
will not be considered the same, because one is owned by a module and
the other is owned by the global module.
If the user code was in a module, then doing a declaration of such
function makes this name owned by the user module, not the module you
expect to import.

So modules add another layer of fine-grained control over what can or
not be accessed, but based on available names,
while this example you gave isolates a function by making it not
visible at link-time (through object files interface (I'm not sure how
it's called)).

For this specific example, the difference might not be obvious. ^^

> So i just give you a small example of how I saw things, but there are pro=
bably a lot of related problems which need to be resolved, for example how =
template should be handled when using this model. I didn't try to solve all=
 this since my goal is just to make you understand what I mean by "an appro=
ach where the exported symbols are deduced from the code". Also I believe t=
hat most of the choice made for the module proposal could apply to this mod=
el as well.
>

Templates are simple with modules because they are not special:
exported template names are visible from user code that imported the
module.

// mymodule.mxx
export module mymodule;

template<class T> auto foo(T value) { return value;} // not exported

export template<class T> auto bar(T value) { return foo(value); } // export=
ed

// usercode.cpp
import mymodule;

void lol()
{
   int x =3D foo(42); // ERROR: foo does not exist (it is not in the
available names)
   int y =3D bar(0); // ok, bar is from module `mymodule`
}

Then in term of compilation+linking, this basically means that it is
possible for compilers to process templates in a form maybe useful for
some optimization.
As importing will only add names to the pool of available names,
importing don't imply (as you understood before) re-parsing the
template.
Which is already a big win in our current heavily templated C++ world.

A. Jo=C3=ABl Lamotte

--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/CAOU91OP5vDkST9iU3DCnTrVuZYxo59PJ_36-BzaBeyZs1tU=
KRA%40mail.gmail.com.

.

------=_Part_85_1657821239.1544652966500
Content-Type: multipart/alternative;
 boundary="----=_Part_86_1750060011.1544652966501"

------=_Part_86_1750060011.1544652966501
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable



Le mercredi 12 d=C3=A9cembre 2018 13:16:02 UTC+1, Klaim - Jo=C3=ABl Lamotte=
 a =C3=A9crit :
>
> On Tue, 11 Dec 2018 at 23:06, <masse....@gmail.com <javascript:>> wrote:=
=20
>
> > From this code, you can easily say that importing this file will import=
=20
> the declaration of the 2 structs, the first one being just a POD data typ=
e,=20
> while the second will have a ctor from a std::string and also a method=20
> format with the given signature.=20
> > Note that in this example, the implementation of the ctor and the forma=
t=20
> method could be in the same cpp file but don't require to, since the=20
> declaration of the class is enough.=20
>
> I am not sure I understand your point because the code you are giving=20
> as example is not a module nor is it exporting anything.=20
>
This is the key idea here :)
In module, things should be exported *explicitely*.
My idea is to deduce what is visible outside from the source, making them=
=20
exported *implicitely*.

Perhaps what is missing in my example is how could the sample.cpp be=20
imported, so here i'll complete it:

/* file basic_logger.cpp */

import std.io; // here I import a pre-built module
import std.string; // here I import another pre-built module
import "sample.cpp" // here I import a file directly
namespace sample
{
class basic_logger
{
std::ostream m_file;
event_printer m_printer;
public:
basic_logger(const std.string& fn)
: m_file(fn), m_printer("%f %l %m") /*assume this will format our event by=
=20
printting the filename, then the line number, then the message */
{ }

void log(const event& e)
{
m_file << m_printer.format(e) << std;;endl;
}

};

}

Now I could import my class basic_logger by importing the file=20
basic_logger.cpp:
/* file main.cpp */

import "basic_logger.cpp"

int main(int argc, char **argv)
{
sample::basic_logger logger("stdout");
event e { "Hello", "World", __FILE__, __LINE__ };
logger.log(e);
return 0;
}


Let's say that you add the `module blah;` line first, then this is not=20
> exporting anything without you explicitely adding `export` keyword in=20
> front of declarations or forward declarations or definitions.=20
> So I don't understand what you mean exactly.=20
>
> >> The problem we have today with headers is that everything=20
> >> in a header needs to be parsed, whether part of the actual=20
> >> interface of the library or not.=20
> >=20
> >=20
> > The idea here is to parse the file only once and to save the "visible"=
=20
> part of it in a specific file.=20
>
> Note that the standard don't say it should end up in a file. It's a=20
> representation stored somewhere. It could be a database of=20
> intermediate representation for example.=20
>
> I didn't knew, but this is ok for me.

> >  The next time this file will be imported, we could just extract the=20
> visible part from the generated file (since the source file didn't change=
=20
> since the other one was generated), avoiding then to re-parse the source.=
=20
>
> Not only that. In non-template cases the code have already been=20
> "compiled" so only it's name and interface are checked when importing.=20
> This means that it's not like having the declaration of such function=20
> (for example) copy pasted where you import, it's more like adding the=20
> name and/or signature of the function to a pool of available names.=20
> There is no syntactic collision possible, compared to headers.=20
>
> For templates, some optimization might be possible (apparently) but=20
> it's still implicitely inline code so whatever goes. In any way,=20
> importing templates is still "adding names to the pool of available=20
> names".=20
> Or you should think that way anyway.=20
>
I think this is almost it, but the difference is that with template the=20
implementation should be available in order to be able to instantiate it.
If the implementation is in the same file than the declaration, then it's=
=20
no problem.
But if the implementation is in another file, then it can be a little more=
=20
complicated, because when should then import this other file too. And also=
=20
this has as consequence the fact that this other file should implicitely=20
export the template's implementation, even if the declaration is somewhere=
=20
else...
Well, since I was only giving an example here, I think we can avoid this=20
kind of problems, at least for now.
=20

> >> Modules give us control over what=20
> >> things are part of the interface and what things are not.=20
> >=20
> >=20
> > Yeah, something in my approach is more or less missing here. More or=20
> less I said? Yes, because in fact this partially already exists. I mean,=
=20
> take this code for example:=20
> >=20
> > //sample_details.cpp=20
> >=20
> > static void print_message(std::string& msg, const event& ev)=20
> > {=20
> >     msg.append(ev.message);=20
> > }=20
> >=20
> > Here you know that the method print_message won't be exported by the=20
> compiler, and thus non-visible outside of the sample_details.cpp file. Ev=
en=20
> if you import this file (which shouldn't be done if we take the logic of =
my=20
> example into account), this method won't be imported because it is intern=
al=20
> to the sample_details.cpp file.=20
> > In fact, this mechanism is inherited from C, meaning that it exists fro=
m=20
> a long time. But unfortunately, it use the static keyword, which could ha=
ve=20
> different meanings when used inside a class. Perhaps deprecating the use =
of=20
> static in this context and replacing it by something else (say internal f=
or=20
> example) could do the trick.=20
> >=20
>
> Here you are describing symbol visibility which is orthogonal to what=20
> modules does, though if you mark a functions static it cannot be=20
> exported through modules (if my memory is correct).=20
> There are big differences. If your static function is part of a=20
> module, then it also mean that other modules can have the same=20
> functioon name in them, even if they end up compiled in the same=20
> binary (ODR is not violated because this function is identified as=20
> owned by the module, so can be differenciated from another function=20
> with same name and same signature and same namespace but ownd by=20
> another module).=20
> Module ownership is unrelated to symbol visibility, but it's maybe=20
> hard to see the nuance.=20
>
I think we have a semantic problem here, because we use some terms like=20
"exported" for differents usages, leading to some confusion between us.=20
Perhaps finding differents terms for each usage will help to clarify things=
..
Personnaly, I see 2 levels of "visibilty" (unsure this is the good term for=
=20
it):
- The 1st level is about what you can see from the compiled version of your=
=20
file (basically the object file), and is what symbols are available when=20
your object file is linked with other ones in a same binary.=20
For making the distinction between what is available from other source=20
files and what is not, i'd like to use the terms internal (unavailable) and=
=20
external (available), but perhaps the fact that I did come C# in the past=
=20
influences me.
In my proposition, symbols will be external (available) by default. For=20
making them internal (unavailable), you could mar them with the (new)=20
"internal" keyword. This is almost the same than using the "static" keyword=
=20
on free methods.

- The 2nd level of "visibilty" is when you are linking your binary to=20
another binary (a static or shared library).
This is what you deals with when using the visibility attribute of=20
gcc/clang, also I think that using the visible/hidden terms for making the=
=20
distinction at this 2nd level could be fairly natural since it is what=20
gcc/clang uses.

To be short, let's say this code is in a module. That you put a static=20
> or not in front of it, as long as you didn't export this function,=20
> it's owned by the module and not exported, therefore nobody can=20
> "compile" with it.=20
> If someone does a declaration in their cpp file of such function which=20
> is owned by a separate module, my understanding is that it will end in=20
> a link error as the function in the module and the function declared=20
> will not be considered the same, because one is owned by a module and=20
> the other is owned by the global module.=20
>
If the user code was in a module, then doing a declaration of such=20
> function makes this name owned by the user module, not the module you=20
> expect to import.=20
>
> So modules add another layer of fine-grained control over what can or=20
> not be accessed, but based on available names,=20
> while this example you gave isolates a function by making it not=20
> visible at link-time (through object files interface (I'm not sure how=20
> it's called)).=20
>
Isn't it what namespaces are there for?
Your answer tend to confirm something I already spotted before, the fact=20
that modules and namespaces does overlap each-other for this kind of usage.

Still, I agree on the fact that modules add a 3rd level of visibility.
It add to the distinction between what can be seen at the object file level=
=20
and to the distinction between what can be seen at the library level, a=20
distinction between what can be seen from the inside and from the outside=
=20
of the module.
My question here is: Is this distinction usefull?
I mean, so far i've never worked on a project where such a distinction=20
could be usefull, but perhaps do you have (or other people have) differents=
=20
experiences than I have.


> For this specific example, the difference might not be obvious. ^^=20
>
> > So i just give you a small example of how I saw things, but there are=
=20
> probably a lot of related problems which need to be resolved, for example=
=20
> how template should be handled when using this model. I didn't try to sol=
ve=20
> all this since my goal is just to make you understand what I mean by "an=
=20
> approach where the exported symbols are deduced from the code". Also I=20
> believe that most of the choice made for the module proposal could apply =
to=20
> this model as well.=20
> >=20
>
> Templates are simple with modules because they are not special:=20
> exported template names are visible from user code that imported the=20
> module.=20
>
> // mymodule.mxx=20
> export module mymodule;=20
>
> template<class T> auto foo(T value) { return value;} // not exported=20
>
> export template<class T> auto bar(T value) { return foo(value); } //=20
> exported=20
>
> // usercode.cpp=20
> import mymodule;=20
>
> void lol()=20
> {=20
>    int x =3D foo(42); // ERROR: foo does not exist (it is not in the=20
> available names)=20
>    int y =3D bar(0); // ok, bar is from module `mymodule`=20
> }=20
>
> Then in term of compilation+linking, this basically means that it is=20
> possible for compilers to process templates in a form maybe useful for=20
> some optimization.=20
> As importing will only add names to the pool of available names,=20
> importing don't imply (as you understood before) re-parsing the=20
> template.=20
> Which is already a big win in our current heavily templated C++ world. =
=20


> A. Jo=C3=ABl Lamotte=20
>

Masse Nicolas.=20

--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/dd92a815-5513-4020-afe2-6bedc53a8c97%40isocpp.or=
g.

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

<div dir=3D"ltr"><br><br>Le mercredi 12 d=C3=A9cembre 2018 13:16:02 UTC+1, =
Klaim - Jo=C3=ABl Lamotte a =C3=A9crit=C2=A0:<blockquote class=3D"gmail_quo=
te" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;paddi=
ng-left: 1ex;">On Tue, 11 Dec 2018 at 23:06, &lt;<a href=3D"javascript:" ta=
rget=3D"_blank" gdf-obfuscated-mailto=3D"7OgXyoFaBAAJ" rel=3D"nofollow" onm=
ousedown=3D"this.href=3D&#39;javascript:&#39;;return true;" onclick=3D"this=
..href=3D&#39;javascript:&#39;;return true;">masse....@gmail.com</a>&gt; wro=
te:
<br>
<br>&gt; From this code, you can easily say that importing this file will i=
mport the declaration of the 2 structs, the first one being just a POD data=
 type, while the second will have a ctor from a std::string and also a meth=
od format with the given signature.
<br>&gt; Note that in this example, the implementation of the ctor and the =
format method could be in the same cpp file but don&#39;t require to, since=
 the declaration of the class is enough.
<br>
<br>I am not sure I understand your point because the code you are giving
<br>as example is not a module nor is it exporting anything.
<br></blockquote><div>This is the key idea here :)</div><div>In module, thi=
ngs should be exported <b>explicitely</b>.</div><div>My idea is to deduce w=
hat is visible outside from the source, making them exported <b>implicitely=
</b>.</div><div><br></div><div>Perhaps what is missing in my example is how=
 could the sample.cpp be imported, so here i&#39;ll complete it:<br></div><=
div><div><br></div><div>/* file basic_logger.cpp */</div><div><br></div><di=
v>import std.io; // here I import a pre-built module</div><div>import std.s=
tring; // here I import another pre-built module</div></div><div>import &qu=
ot;sample.cpp&quot; // here I import a file directly<br></div><div>namespac=
e sample</div><div>{</div><div>class basic_logger<br></div><div>{</div><div=
>std::ostream m_file;</div><div>event_printer m_printer;<br></div><div>publ=
ic:</div><div>basic_logger(const std.string&amp; fn)</div><div> : m_file(fn=
), m_printer(&quot;%f %l %m&quot;) /*assume this will format our event by p=
rintting the filename, then the line number, then the message */<br></div><=
div>{ }</div><div><br></div><div>void log(const event&amp; e)</div><div>{</=
div><div>m_file &lt;&lt; m_printer.format(e) &lt;&lt; std;;endl;<br></div><=
div>}</div><div><br></div><div>};</div><div><br></div><div>}<br></div><div>=
<br></div><div>Now I could import my class basic_logger by importing the fi=
le basic_logger.cpp:<div></div><div>/* file main.cpp */</div></div><div><br=
></div><div>import &quot;basic_logger.cpp&quot;</div><div><br></div><div>in=
t main(int argc, char **argv)</div><div>{</div><div>sample::basic_logger lo=
gger(&quot;stdout&quot;);</div><div>event e { &quot;Hello&quot;, &quot;Worl=
d&quot;, __FILE__, __LINE__ };</div><div>logger.log(e);</div><div>return 0;=
<br></div><div>}<br></div><div><br></div><div><br></div><blockquote class=
=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #cc=
c solid;padding-left: 1ex;">Let&#39;s say that you add the `module blah;` l=
ine first, then this is not
<br>exporting anything without you explicitely adding `export` keyword in
<br>front of declarations or forward declarations or definitions.
<br>So I don&#39;t understand what you mean exactly.
<br>
<br>&gt;&gt; The problem we have today with headers is that everything
<br>&gt;&gt; in a header needs to be parsed, whether part of the actual
<br>&gt;&gt; interface of the library or not.
<br>&gt;
<br>&gt;
<br>&gt; The idea here is to parse the file only once and to save the &quot=
;visible&quot; part of it in a specific file.
<br>
<br>Note that the standard don&#39;t say it should end up in a file. It&#39=
;s a
<br>representation stored somewhere. It could be a database of
<br>intermediate representation for example.
<br>
<br></blockquote><div>I didn&#39;t knew, but this is ok for me.<br></div><b=
lockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;borde=
r-left: 1px #ccc solid;padding-left: 1ex;">&gt; =C2=A0The next time this fi=
le will be imported, we could just extract the visible part from the genera=
ted file (since the source file didn&#39;t change since the other one was g=
enerated), avoiding then to re-parse the source.
<br>
<br>Not only that. In non-template cases the code have already been
<br>&quot;compiled&quot; so only it&#39;s name and interface are checked wh=
en importing.
<br>This means that it&#39;s not like having the declaration of such functi=
on
<br>(for example) copy pasted where you import, it&#39;s more like adding t=
he
<br>name and/or signature of the function to a pool of available names.
<br>There is no syntactic collision possible, compared to headers.
<br>
<br>For templates, some optimization might be possible (apparently) but
<br>it&#39;s still implicitely inline code so whatever goes. In any way,
<br>importing templates is still &quot;adding names to the pool of availabl=
e
<br>names&quot;.
<br>Or you should think that way anyway.
<br></blockquote><div>I think this is almost it, but the difference is that=
 with template the implementation should be available in order to be able t=
o instantiate it.</div><div>If the implementation is in the same file than =
the declaration, then it&#39;s no problem.</div><div>But if the implementat=
ion is in another file, then it can be a little more complicated, because w=
hen should then import this other file too. And also this has as consequenc=
e the fact that this other file should implicitely export the template&#39;=
s implementation, even if the declaration is somewhere else...</div><div>We=
ll, since I was only giving an example here, I think we can avoid this kind=
 of problems, at least for now.<br></div><div>=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;">&gt;&gt; Modules give us control over what
<br>&gt;&gt; things are part of the interface and what things are not.
<br>&gt;
<br>&gt;
<br>&gt; Yeah, something in my approach is more or less missing here. More =
or less I said? Yes, because in fact this partially already exists. I mean,=
 take this code for example:
<br>&gt;
<br>&gt; //sample_details.cpp
<br>&gt;
<br>&gt; static void print_message(std::string&amp; msg, const event&amp; e=
v)
<br>&gt; {
<br>&gt; =C2=A0 =C2=A0 msg.append(ev.message);
<br>&gt; }
<br>&gt;
<br>&gt; Here you know that the method print_message won&#39;t be exported =
by the compiler, and thus non-visible outside of the sample_details.cpp fil=
e. Even if you import this file (which shouldn&#39;t be done if we take the=
 logic of my example into account), this method won&#39;t be imported becau=
se it is internal to the sample_details.cpp file.
<br>&gt; In fact, this mechanism is inherited from C, meaning that it exist=
s from a long time. But unfortunately, it use the static keyword, which cou=
ld have different meanings when used inside a class. Perhaps deprecating th=
e use of static in this context and replacing it by something else (say int=
ernal for example) could do the trick.
<br>&gt;
<br>
<br>Here you are describing symbol visibility which is orthogonal to what
<br>modules does, though if you mark a functions static it cannot be
<br>exported through modules (if my memory is correct).
<br>There are big differences. If your static function is part of a
<br>module, then it also mean that other modules can have the same
<br>functioon name in them, even if they end up compiled in the same
<br>binary (ODR is not violated because this function is identified as
<br>owned by the module, so can be differenciated from another function
<br>with same name and same signature and same namespace but ownd by
<br>another module).
<br>Module ownership is unrelated to symbol visibility, but it&#39;s maybe
<br>hard to see the nuance.
<br></blockquote><div>I think we have a semantic problem here, because we u=
se some terms like &quot;exported&quot; for differents usages, leading to s=
ome confusion between us. Perhaps finding differents terms for each usage w=
ill help to clarify things.<br></div><div>Personnaly, I see 2 levels of &qu=
ot;visibilty&quot; (unsure this is the good term for it):</div><div>- The 1=
st level is about what you can see from the compiled version of your file (=
basically the object file), and is what symbols are available when your obj=
ect file is linked with other ones in a same binary. <br></div><div>For mak=
ing the distinction between what is available from other source files and w=
hat is not, i&#39;d like to use the terms internal (unavailable) and extern=
al (available), but perhaps the fact that I did come C# in the past influen=
ces me.</div><div>In my proposition, symbols will be external (available) b=
y default. For making them internal (unavailable), you could mar them with =
the (new) &quot;internal&quot; keyword. This is almost the same than using =
the &quot;static&quot; keyword on free methods.</div><div><br></div><div>- =
The 2nd level of &quot;visibilty&quot; is when you are linking your binary =
to another binary (a static or shared library).</div><div>This is what you =
deals with when using the visibility attribute of gcc/clang, also I think t=
hat using the visible/hidden terms for making the distinction at this 2nd l=
evel could be fairly natural since it is what gcc/clang uses.<br></div><div=
><br></div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left=
: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">To be short, let&#3=
9;s say this code is in a module. That you put a static
<br>or not in front of it, as long as you didn&#39;t export this function,
<br>it&#39;s owned by the module and not exported, therefore nobody can
<br>&quot;compile&quot; with it.
<br>If someone does a declaration in their cpp file of such function which
<br>is owned by a separate module, my understanding is that it will end in
<br>a link error as the function in the module and the function declared
<br>will not be considered the same, because one is owned by a module and
<br>the other is owned by the global module.
<br></blockquote><blockquote class=3D"gmail_quote" style=3D"margin: 0;margi=
n-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">If the user c=
ode was in a module, then doing a declaration of such
<br>function makes this name owned by the user module, not the module you
<br>expect to import.
<br>
<br>So modules add another layer of fine-grained control over what can or
<br>not be accessed, but based on available names,
<br>while this example you gave isolates a function by making it not
<br>visible at link-time (through object files interface (I&#39;m not sure =
how
<br>it&#39;s called)).
<br></blockquote><div>Isn&#39;t it what namespaces are there for?</div><div=
>Your answer tend to confirm something I already spotted before, the fact t=
hat modules and namespaces does overlap each-other for this kind of usage.<=
/div><div><br></div><div>Still, I agree on the fact that modules add a 3rd =
level of visibility.</div><div>It add to the distinction between what can b=
e seen at the object file level and to the distinction between what can be =
seen at the library level, a distinction between what can be seen from the =
inside and from the outside of the module.</div><div>My question here is: I=
s this distinction usefull?</div><div>I mean, so far i&#39;ve never worked =
on a project where such a distinction could be usefull, but perhaps do you =
have (or other people have) differents experiences than I have.<br></div><d=
iv></div><div><br></div><blockquote class=3D"gmail_quote" style=3D"margin: =
0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">
<br>For this specific example, the difference might not be obvious. ^^
<br>
<br>&gt; So i just give you a small example of how I saw things, but there =
are probably a lot of related problems which need to be resolved, for examp=
le how template should be handled when using this model. I didn&#39;t try t=
o solve all this since my goal is just to make you understand what I mean b=
y &quot;an approach where the exported symbols are deduced from the code&qu=
ot;. Also I believe that most of the choice made for the module proposal co=
uld apply to this model as well.
<br>&gt;
<br>
<br>Templates are simple with modules because they are not special:
<br>exported template names are visible from user code that imported the
<br>module.
<br>
<br>// mymodule.mxx
<br>export module mymodule;
<br>
<br>template&lt;class T&gt; auto foo(T value) { return value;} // not expor=
ted
<br>
<br>export template&lt;class T&gt; auto bar(T value) { return foo(value); }=
 // exported
<br>
<br>// usercode.cpp
<br>import mymodule;
<br>
<br>void lol()
<br>{
<br>=C2=A0 =C2=A0int x =3D foo(42); // ERROR: foo does not exist (it is not=
 in the
<br>available names)
<br>=C2=A0 =C2=A0int y =3D bar(0); // ok, bar is from module `mymodule`
<br>}
<br>
<br>Then in term of compilation+linking, this basically means that it is
<br>possible for compilers to process templates in a form maybe useful for
<br>some optimization.
<br>As importing will only add names to the pool of available names,
<br>importing don&#39;t imply (as you understood before) re-parsing the
<br>template.
<br>Which is already a big win in our current heavily templated C++ world.
=C2=A0</blockquote><blockquote class=3D"gmail_quote" style=3D"margin: 0;mar=
gin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">
<br>A. Jo=C3=ABl Lamotte
<br></blockquote><div><br></div><div>Masse Nicolas. <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/dd92a815-5513-4020-afe2-6bedc53a8c97%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/dd92a815-5513-4020-afe2-6bedc53a8c97=
%40isocpp.org</a>.<br />

------=_Part_86_1750060011.1544652966501--

------=_Part_85_1657821239.1544652966500--

.

------=_Part_87_1737046625.1544653831996
Content-Type: multipart/alternative;
 boundary="----=_Part_88_1158070116.1544653831996"

------=_Part_88_1158070116.1544653831996
Content-Type: text/plain; charset="UTF-8"


>
>
> - The 2nd level of "visibilty" is when you are linking your binary to
> another binary (a static or shared library).
> This is what you deals with when using the visibility attribute of
> gcc/clang, also I think that using the visible/hidden terms for making the
> distinction at this 2nd level could be fairly natural since it is what
> gcc/clang uses.
>
> After checking, gcc accept the values default/internal/hidden/protected
for the visibility attribute, and relate to the visibility of elf binaries
(I though it was visible/hidden, but it seems i was mistaken here :) ).
This makes my proposition less relevant then.

--
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/a8914c82-625b-4f20-88fe-c3e7741b3777%40isocpp.org.

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

<div dir=3D"ltr"><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"><br><div>- The 2nd level of &quot;visibilty&quot; is when you are linki=
ng your binary to another binary (a static or shared library).</div><div>Th=
is is what you deals with when using the visibility attribute of gcc/clang,=
 also I think that using the visible/hidden terms for making the distinctio=
n at this 2nd level could be fairly natural since it is what gcc/clang uses=
..<br></div><br></div></blockquote><div>After checking, gcc accept the value=
s default/internal/hidden/protected for the visibility attribute, and relat=
e to the visibility of elf binaries (I though it was visible/hidden, but it=
 seems i was mistaken here :) ).</div><div>This makes my proposition less r=
elevant then.</div><div><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/a8914c82-625b-4f20-88fe-c3e7741b3777%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/a8914c82-625b-4f20-88fe-c3e7741b3777=
%40isocpp.org</a>.<br />

------=_Part_88_1158070116.1544653831996--

------=_Part_87_1737046625.1544653831996--

.