------=_Part_753_408735194.1416621698908
Content-Type: multipart/alternative;
 boundary="----=_Part_754_1959702452.1416621698908"

------=_Part_754_1959702452.1416621698908
Content-Type: text/plain; charset=UTF-8

I have been reading a lot about modules lately, and their potential use in
the future of C++. Personally I find the shift very appealing and am
looking forward to seeing its implementation. My favorite approach to the
concept has been the one taken by the developers of Clang. However, one
angle I have not seen explored is the possibility of lazy symbol resolution
(i.e allowing the usage of a type/function before its declaration) within
module compilation.

This would massively simplify some aspects of C++ code, and more
importantly eliminate the reason Header files were introduced in the first
place. Furthermore, this would allow for parallelization of module
compilation, as modules could be compiled (though not linked) before their
dependencies. During linkage, the compiler could enumerate through the
exported types/functions of imported modules and then determine if a
type/function is truly absent. The proposals I have seen so far for modules
mostly eliminate the possibility of parallel compilation, as they assume a
tree-like structure for module dependencies.

Parallelization aside, I've found forward-declerations and umbrella header
files (ensuring users of the library include headers in the right order to
resolve declarations) do nothing but add unnecessary clutter to my
codebases, and force me to spend more time fighting the compiler than
actually writing code.

Additionally, the enumeration of types exported from modules could
potentially pave the way for a clean standard reflection system, assuming
that data was saved alongside everything else (which could be disabled, for
distribution on systems with limited memory).

Anyway, those are just my thoughts. I can't claim to be an expert on
compilers, but the lack of this feature (modules or no) feels like nothing
but an infuriating holdover from the days from when compilers ran on
memory-strapped computers. The most popular modern languages (many of which
were inspired by C++) have this feature, so I think its about time we did
too. While C++ is certainly a low(ish) level language, that doesn't mean
that interacting with its compilers has to feel like a hostage negotiation.

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

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

<div dir=3D"ltr">I have been reading a lot about modules lately, and their =
potential use in the future of C++. Personally I find the shift very appeal=
ing and am looking forward to seeing its implementation. My favorite approa=
ch to the concept has been the one taken by the developers of Clang. Howeve=
r, one angle I have not seen explored is the possibility of lazy symbol res=
olution (i.e allowing the usage of a type/function before its declaration) =
within module compilation.<br><br>This would massively simplify some aspect=
s of C++ code, and more importantly eliminate the reason Header files were =
introduced in the first place. Furthermore, this would allow for paralleliz=
ation of module compilation, as modules could be compiled (though not linke=
d) before their dependencies. During linkage, the compiler could enumerate =
through the exported types/functions of imported modules and then determine=
 if a type/function is truly absent. The proposals I have seen so far for m=
odules mostly eliminate the possibility of parallel compilation, as they as=
sume a tree-like structure for module dependencies.<br><br>Parallelization =
aside, I've found forward-declerations and umbrella header files (ensuring =
users of the library include headers in the right order to resolve declarat=
ions) do nothing but add unnecessary clutter to my codebases, and force me =
to spend more time fighting the compiler than actually writing code.<br><br=
>Additionally, the enumeration of types exported from modules could potenti=
ally pave the way for a clean standard reflection system, assuming that dat=
a was saved alongside everything else (which could be disabled, for distrib=
ution on systems with limited memory).<br><br>Anyway, those are just my tho=
ughts. I can't claim to be an expert on compilers, but the lack of this fea=
ture (modules or no) feels like nothing but an infuriating holdover from th=
e days from when compilers ran on memory-strapped computers. The most popul=
ar modern languages (many of which were inspired by C++) have this feature,=
 so I think its about time we did too. While C++ is certainly a low(ish) le=
vel language, that doesn't mean that interacting with its compilers has to =
feel like a hostage negotiation.<br></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_754_1959702452.1416621698908--
------=_Part_753_408735194.1416621698908--

.

On Friday 21 November 2014 18:01:38 Will Cassella wrote:
> I have been reading a lot about modules lately, and their potential use in
> the future of C++. Personally I find the shift very appealing and am
> looking forward to seeing its implementation. My favorite approach to the
> concept has been the one taken by the developers of Clang. However, one
> angle I have not seen explored is the possibility of lazy symbol resolution
> (i.e allowing the usage of a type/function before its declaration) within
> module compilation.

I don't think this will ever happen.

All functions need to be forward declared with their full parameter list and
return types before they can be called or their address taken, all global
variables must be extern-declared before their address can be taken and for
that all aggregates must be forward-declared. Additionally, before any type
can be constructed, it needs to be fully declared.

That is not going to change.
--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center
      PGP/GPG: 0x6EF45358; fingerprint:
      E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

.

------=_Part_99_503115908.1416629757017
Content-Type: multipart/alternative;
 boundary="----=_Part_100_1225947517.1416629757017"

------=_Part_100_1225947517.1416629757017
Content-Type: text/plain; charset=UTF-8

Why not? I can see how C++ has quite a bit of momentum going with this, but
it seems that removing the restriction of declaration-before-use would only
make the language easier to use. It has been implemented successfully in
other languages, so I don't see why c++ should be any different. Is there
anything unique to C++ that prevents doing so?

On Friday, November 21, 2014 9:05:17 PM UTC-7, Thiago Macieira wrote:
>
> On Friday 21 November 2014 18:01:38 Will Cassella wrote:
> > I have been reading a lot about modules lately, and their potential use
> in
> > the future of C++. Personally I find the shift very appealing and am
> > looking forward to seeing its implementation. My favorite approach to
> the
> > concept has been the one taken by the developers of Clang. However, one
> > angle I have not seen explored is the possibility of lazy symbol
> resolution
> > (i.e allowing the usage of a type/function before its declaration)
> within
> > module compilation.
>
> I don't think this will ever happen.
>
> All functions need to be forward declared with their full parameter list
> and
> return types before they can be called or their address taken, all global
> variables must be extern-declared before their address can be taken and
> for
> that all aggregates must be forward-declared. Additionally, before any
> type
> can be constructed, it needs to be fully declared.
>
> That is not going to change.
> --
> Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
>    Software Architect - Intel Open Source Technology Center
>       PGP/GPG: 0x6EF45358; fingerprint:
>       E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358
>
>

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

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

<div dir=3D"ltr">Why not? I can see how C++ has quite a bit of momentum goi=
ng with this, but it seems that removing the restriction of declaration-bef=
ore-use would only make the language easier to use. It has been implemented=
 successfully in other languages, so I don't see why c++ should be any diff=
erent. Is there anything unique to C++ that prevents doing so?<br><br>On Fr=
iday, November 21, 2014 9:05:17 PM UTC-7, Thiago Macieira wrote:<blockquote=
 class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1=
px #ccc solid;padding-left: 1ex;">On Friday 21 November 2014 18:01:38 Will =
Cassella wrote:
<br>&gt; I have been reading a lot about modules lately, and their potentia=
l use in=20
<br>&gt; the future of C++. Personally I find the shift very appealing and =
am=20
<br>&gt; looking forward to seeing its implementation. My favorite approach=
 to the=20
<br>&gt; concept has been the one taken by the developers of Clang. However=
, one=20
<br>&gt; angle I have not seen explored is the possibility of lazy symbol r=
esolution=20
<br>&gt; (i.e allowing the usage of a type/function before its declaration)=
 within
<br>&gt; module compilation.
<br>
<br>I don't think this will ever happen.
<br>
<br>All functions need to be forward declared with their full parameter lis=
t and=20
<br>return types before they can be called or their address taken, all glob=
al=20
<br>variables must be extern-declared before their address can be taken and=
 for=20
<br>that all aggregates must be forward-declared. Additionally, before any =
type=20
<br>can be constructed, it needs to be fully declared.
<br>
<br>That is not going to change.
<br>--=20
<br>Thiago Macieira - thiago (AT) <a href=3D"http://macieira.info" target=
=3D"_blank" onmousedown=3D"this.href=3D'http://www.google.com/url?q\75http%=
3A%2F%2Fmacieira.info\46sa\75D\46sntz\0751\46usg\75AFQjCNEswDUBNCNanbu7euhq=
Ln_62FW8ag';return true;" onclick=3D"this.href=3D'http://www.google.com/url=
?q\75http%3A%2F%2Fmacieira.info\46sa\75D\46sntz\0751\46usg\75AFQjCNEswDUBNC=
Nanbu7euhqLn_62FW8ag';return true;">macieira.info</a> - thiago (AT) <a href=
=3D"http://kde.org" target=3D"_blank" onmousedown=3D"this.href=3D'http://ww=
w.google.com/url?q\75http%3A%2F%2Fkde.org\46sa\75D\46sntz\0751\46usg\75AFQj=
CNHGRJdo5_JYG1DowztwAHAKs80XSA';return true;" onclick=3D"this.href=3D'http:=
//www.google.com/url?q\75http%3A%2F%2Fkde.org\46sa\75D\46sntz\0751\46usg\75=
AFQjCNHGRJdo5_JYG1DowztwAHAKs80XSA';return true;">kde.org</a>
<br>&nbsp; &nbsp;Software Architect - Intel Open Source Technology Center
<br>&nbsp; &nbsp; &nbsp; PGP/GPG: 0x6EF45358; fingerprint:
<br>&nbsp; &nbsp; &nbsp; E067 918B B660 DBD1 105C &nbsp;966C 33F5 F005 6EF4=
 5358
<br>
<br></blockquote></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_100_1225947517.1416629757017--
------=_Part_99_503115908.1416629757017--

.

On Friday 21 November 2014 20:15:57 Will Cassella wrote:
> Why not? I can see how C++ has quite a bit of momentum going with this, but
> it seems that removing the restriction of declaration-before-use would only
> make the language easier to use. It has been implemented successfully in
> other languages, so I don't see why c++ should be any different. Is there
> anything unique to C++ that prevents doing so?

Because it would be a different language. Doing anything remotely like what you
asked for (if I understood you right) would implicitly change all the rules of
overloading and throw away binary compatibility for any compiler that existed.

It's simply not possible to do it.

The declaration needs to be present, even if imported via modules somehow.
That is to say, it's possible to remove the declarations as they exist today
(via headers), but they need to be replaced with something else.

--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center
      PGP/GPG: 0x6EF45358; fingerprint:
      E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

.

------=_Part_199_1050926665.1416642678990
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Even parsing C++ without knowing type information isn't possible, though th=
is could be worked around by adding typename and template as needed to disa=
mbiguate.  Compiling, or even instantiating templates, most certainly would=
 require complete information.  Therefore what you are suggesting could in =
principle be supported I think with only minimal language changes by separa=
ting the parsing step from the compilation step.  Parsing of a module would=
 produce some efficient binary representation of it, but would not generate=
 any machine code, and would not depend on the imported modules already bei=
ng parsed.  The compilation step would depend on the parsing but not the co=
mpilation of all imported modules.  The cost is that every imported type or=
 template would have to be annotated as such using the typename and templat=
e keywords as if they were dependent names in a template.

Whether this two step procedure would actually be faster in practice is unc=
lear.  Also everything I said ignores the fact that clang allows modules to=
 export preprocessor macros.  To handle that we would need a 3 step procedu=
re.

--=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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

------=_Part_199_1050926665.1416642678990--

.

Will Cassella <wcassella@gmail.com> writes:

| I have been reading a lot about modules lately, and their potential
| use in the future of C++. Personally I find the shift very appealing
| and am looking forward to seeing its implementation. My favorite
| approach to the concept has been the one taken by the developers of
| Clang. However, one angle I have not seen explored is the possibility
| of lazy symbol resolution (i.e allowing the usage of a type/function
| before its declaration) within module compilation.

"Lazy symbol" resolution appears to be an "implementation detail".
(That is the default implementation strategy that some C++ implementations
working on the module proposal take though.)

-- Gaby

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

.

Will Cassella <wcassella@gmail.com> writes:

| Why not? I can see how C++ has quite a bit of momentum going with
| this, but it seems that removing the restriction of
| declaration-before-use would only make the language easier to use. It
| has been implemented successfully in other languages, so I don't see
| why c++ should be any different. Is there anything unique to C++ that
| prevents doing so?

If you remove "declaration-before-use", you've just made C++ nearly
impossible to parse or certainly changed the semantics of existing
well-formed programs.

-- Gaby
]

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

.

On Saturday 22 November 2014 19:21:12 Gabriel Dos Reis wrote:
> Will Cassella <wcassella@gmail.com> writes:
> | I have been reading a lot about modules lately, and their potential
> | use in the future of C++. Personally I find the shift very appealing
> | and am looking forward to seeing its implementation. My favorite
> | approach to the concept has been the one taken by the developers of
> | Clang. However, one angle I have not seen explored is the possibility
> | of lazy symbol resolution (i.e allowing the usage of a type/function
> | before its declaration) within module compilation.
>
> "Lazy symbol" resolution appears to be an "implementation detail".
> (That is the default implementation strategy that some C++ implementations
> working on the module proposal take though.)

I thought that when I first read the email, but I don't think he meant that.
The rest of the email isn't talking about symbol resolution.

--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center
      PGP/GPG: 0x6EF45358; fingerprint:
      E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

.

On 2014-11-21 21:01, Will Cassella wrote:
> However, one
> angle I have not seen explored is the possibility of lazy symbol resolution
> (i.e allowing the usage of a type/function before its declaration) within
> module compilation.
>
> This would massively simplify some aspects of C++ code, and more
> importantly eliminate the reason Header files were introduced in the first
> place. Furthermore, this would allow for parallelization of module
> compilation, as modules could be compiled (though not linked) before their
> dependencies.

No, they can't. In order to compile a function/method call, you need to
know what arguments it takes. For example, you might call a function
with a char* and a float, when it actually takes a std::string and a
double. Implicit conversions permit this, but in order for that to
happen, the compiler needs to know at the call site to implicitly create
objects or cast to other POD types.

If you delayed symbol resolution, you would have to be able to go back
and insert this code at a later compiler pass. That *might* work for
some compilers, but I can imagine that it would totally break optimizing
for others.

I don't see how this would ever happen in C++. At the very least, I am
confident it would be rejected as standard practice until there exists a
compiler that implements it.

--
Matthew

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

.