220 41246 article Path: news.gmane.org!.POSTED!not-for-mail From: Masse Nicolas Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Re: Modules and preambule, just why? Date: Wed, 12 Dec 2018 14:16:06 -0800 (PST) Lines: 581 Approved: news@gmane.org Message-ID: References: <9f2c63e2-7904-49ea-a2ac-87e80fe78e78@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_85_1657821239.1544652966500" X-Trace: blaine.gmane.org 1544652844 7417 195.159.176.226 (12 Dec 2018 22:14:04 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Wed, 12 Dec 2018 22:14:04 +0000 (UTC) To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBCCJBHV4UALBBJ4RY3QAKGQEKM6X25Y@isocpp.org Wed Dec 12 23:14:00 2018 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-yw1-f72.google.com ([209.85.161.72]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gXClT-0001nN-0w for gclcip-std-proposals@m.gmane.org; Wed, 12 Dec 2018 23:13:59 +0100 Original-Received: by mail-yw1-f72.google.com with SMTP id v195sf12719ywc.6 for ; Wed, 12 Dec 2018 14:16:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isocpp-org.20150623.gappssmtp.com; s=20150623; h=date:from:to:message-id:in-reply-to:references:subject:mime-version :x-original-sender:reply-to:precedence:mailing-list:list-id :list-post:list-help:list-archive:list-subscribe:list-unsubscribe; bh=taOWnPFfx7CPUz57/evPCrzu7z3OXF/F3kvGaAhHvzI=; b=a4Nht/jpFuMglhU2IjfiaxajXyCLCUksQGMrMjWIduoAwuemLOAeGR/xFUm49OVXHW GdBPNa9y1UjoF4E5EDtPHeVxpB1ZxHKT5sTA7OQ+scStOYTXeBHkACx3XDfM7W2ItnTO h8XdbRCr4RrxxMw8rOZfLQcMrEHPwSp8xV0pKCuGI3VR1DVKUprYcK/CGTv9LOOwLH58 hcskxUsn6iyP6lF7yCAXKe86dX1/yy80DgnoTZPvEXOV++vFr3aiLvXZqH2MMbUGS4eq sZ43urq3OPmVTuN0wABuTEm2yXDp3BoLRVt/MOfusjTbXj1ns1Pe9835q+x8CXD+GZr3 5lsA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:message-id:in-reply-to:references:subject:mime-version :x-original-sender:reply-to:precedence:mailing-list:list-id :list-post:list-help:list-archive:list-subscribe:list-unsubscribe; bh=taOWnPFfx7CPUz57/evPCrzu7z3OXF/F3kvGaAhHvzI=; b=L5czABZ0+mjnsYyoJqYqX1HhikkYhG1junjqsaXbuXH3bHgNt0qBkbWC4Qtno+CtFl hJSriUsrGSBN3VwcsAdNA37lReM4wabAfXgRX+dwfihiyiGPWAlNXky9R3nbiUjcxn5+ 5guQsFt4ACmT7rQufnSre2JVvILrFdp+TjliF1nEqs8+wWkkTtc9JKafICJGOTYCVvn1 pCNzvoSSQJ69McKFHj7qEZg2+RNAOGat3rd7E17bFUq8ZvxL/HUkYJ+5KMU+dIZLrjVP k2qikv/e4JV7PPHTNfjcniwfUpzAAKKM61y9Adjzjq5UJA1o5nIM0hthu2A6fkivxP8U +EYQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:message-id:in-reply-to:references :subject:mime-version:x-original-sender:reply-to:precedence :mailing-list:list-id:x-spam-checked-in-group:list-post:list-help :list-archive:list-subscribe:list-unsubscribe; bh=taOWnPFfx7CPUz57/evPCrzu7z3OXF/F3kvGaAhHvzI=; b=Lr8CKUraFSE2tQ/zIoQd7Cthj9NfUftXacURWoFJqVKb8dKt08bZix0fIYn65PKr6O 6mw1evrfSDdadF6xkHtZ80odTnZIudFns7N42kZQXeB2fBNLfHvf0Rn6jY0OMiWF1OWp RIO0XRZF5JLmIRCfegitqktkzhO06XOIykxe1y5pGmL0FM/fxhUoEgkdoyMjsoqQiJA5 UL8MQB4puJY+cTVA92HaSnq10C7c1nwxVt7qeWgKpwsOlJZzwTxyV/ThIxz5BeOLi7Bm hL9LlKXCHVwFQ8BbHCL4HIzb2CL+6UBrMFPKkelwRRKeTs8wHtq3n9mEGlA3xvApRhdA AEuQ== X-Gm-Message-State: AA+aEWYrSBl3U5inC3YgzpId1338Ri++fPxA+Afrfakuwkwh0QM8Hc7j ZqogsupFlDWTKWbAp0KeKcyZfw== X-Google-Smtp-Source: AFSGD/UWCF1bS/xwdpWHRg3IsWNttL6+UrJnDWo/PQqwC8oPJoa24L7uf4uE/uMmMklmvC2eeyNAng== X-Received: by 2002:a81:3c45:: with SMTP id j66mr13124845ywa.9.1544652969033; Wed, 12 Dec 2018 14:16:09 -0800 (PST) X-BeenThere: std-proposals@isocpp.org Original-Received: by 2002:a0d:de41:: with SMTP id h62ls58723ywe.9.gmail; Wed, 12 Dec 2018 14:16:07 -0800 (PST) X-Received: by 2002:a81:27cd:: with SMTP id n196mr370406ywn.2.1544652967206; Wed, 12 Dec 2018 14:16:07 -0800 (PST) In-Reply-To: X-Original-Sender: Masse.Nicolas@gmail.com Precedence: list Mailing-list: list std-proposals@isocpp.org; contact std-proposals+owners@isocpp.org List-ID: X-Spam-Checked-In-Group: std-proposals@isocpp.org X-Google-Group-Id: 399137483710 List-Post: , List-Help: , List-Archive: List-Subscribe: , List-Unsubscribe: , Xref: news.gmane.org gmane.comp.lang.c++.isocpp.proposals:41246 Archived-At: ------=_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, > 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 auto foo(T value) { return value;} // not exported=20 > > export template 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


Le mercredi 12 d=C3=A9cembre 2018 13:16:02 UTC+1, = Klaim - Jo=C3=ABl Lamotte a =C3=A9crit=C2=A0:
On Tue, 11 Dec 2018 at 23:06, <masse....@gmail.com> wro= te:

> 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.
> 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.

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.
This is the key idea here :)
In module, thi= ngs should be exported explicitely.
My idea is to deduce w= hat is visible outside from the source, making them exported implicitely= .

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

/* file basic_logger.cpp */

import std.io; // here I import a pre-built module
import std.s= tring; // here I import another pre-built module
import &qu= ot;sample.cpp" // here I import a file directly
namespac= e sample
{
class basic_logger
{
std::ostream m_file;
event_printer m_printer;
publ= ic:
basic_logger(const std.string& fn)
: m_file(fn= ), m_printer("%f %l %m") /*assume this will format our event by p= rintting the filename, then the line number, then the message */
<= div>{ }

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

};

}
=
Now I could import my class basic_logger by importing the fi= le basic_logger.cpp:
/* file main.cpp */
import "basic_logger.cpp"

in= t main(int argc, char **argv)
{
sample::basic_logger lo= gger("stdout");
event e { "Hello", "Worl= d", __FILE__, __LINE__ };
logger.log(e);
return 0;=
}


Let's say that you add the `module blah;` l= ine 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" part 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.

I didn't knew, but this is ok for me.
> =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't change since the other one was g= enerated), 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 wh= en importing.
This means that it's not like having the declaration of such functi= on
(for example) copy pasted where you import, it's more like adding t= he
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 availabl= e
names".
Or you should think that way anyway.
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.
If the implementation is in the same file than = the declaration, then it's no problem.
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'= s implementation, even if the declaration is somewhere else...
We= ll, since I was only giving an example here, I think we can avoid this kind= of problems, at least for now.
=C2=A0
>> 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& e= v)
> {
> =C2=A0 =C2=A0 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 fil= e. 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 becau= se it is internal to the sample_details.cpp file.
> 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.
>

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.
I think we have a semantic problem here, because we u= se some terms like "exported" for differents usages, leading to s= ome confusion between us. Perhaps finding differents terms for each usage w= ill help to clarify things.
Personnaly, I see 2 levels of &qu= ot;visibilty" (unsure this is the good term for it):
- 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.
For mak= ing the distinction between what is available from other source files and w= hat is not, i'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.
In my proposition, symbols will be external (available) b= y default. For making them internal (unavailable), you could mar them with = the (new) "internal" keyword. This is almost the same than using = the "static" keyword on free methods.

- = 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 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.

To be short, let= 9;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 c= ode 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)).
Isn't it what namespaces are there for?
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>

Still, I agree on the fact that modules add a 3rd = level of visibility.
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.
My question here is: I= s this distinction usefull?
I mean, so far i'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.


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 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't try t= o solve all this since my goal is just to make you understand what I mean b= y "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.
>

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 expor= ted

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

// usercode.cpp
import mymodule;

void lol()
{
=C2=A0 =C2=A0int x =3D foo(42); // ERROR: foo does not exist (it is not= in the
available names)
=C2=A0 =C2=A0int 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. =C2=A0

A. Jo=C3=ABl Lamotte

Masse Nicolas.

--
You received this message because you are subscribed to the Google Groups &= quot;ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e= mail to std-proposa= ls+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.org.
------=_Part_86_1750060011.1544652966501-- ------=_Part_85_1657821239.1544652966500-- .