Date: Tue, 12 Feb 2019 21:05:57 +0000
* And it took how long after it’s formation for anyone except me to raise their hand and their concerns for modules tooling?
The very first time it had a chance to meet?
Your contributions are very much appreciated and not being diminished in any way by anyone.
* If you didn’t want to talk about C#’s approach to how it handles modules and the differences of it’s language features in comparison to C++, don’t bring it up in the first place.
You misunderstood the statement. What was meant is that the fact that namespaces are module names is irrelevant to the mapping problem.
From: Isabella Muerte <imuerte_at_[hidden]>
Sent: Tuesday, February 12, 2019 1:00 PM
To: Gabriel Dos Reis <gdr_at_[hidden]>; WG21 Tooling Study Group SG15 <tooling_at_[hidden]>
Subject: Re: RE: [Tooling] SG15 Why do we need module name to file name mapping
And it took how long after it’s formation for anyone except me to raise their hand and their concerns for modules tooling? How many ISO meetings before we could even agree on what it’s goal and direction was? Color me unimpressed with the effort of SG15 until very recently.
I do not trust implementors to do the right thing because y’all have shown yourselves incapable of it until recently. You have maybe 5 years of doing the right thing (and that’s generous) backed by 15 years of doing the wrong thing or making false claims like “we’re C++ compliant!” when their library is lacking interfaces for compliance or language features that are required. How many years did it take for us to get all the keywords required by the standard to be enabled by default in msvc without including a header that is supposed to be empty? I do not mistrust out of doubt, but out of experience with three separate implementations.
This and the previous dismissal of my statement is why so many people are concerned about modules. You deflect and move goal posts as is convenient, and this is why we are for the large part dissatisfied with modules as specified. If you didn’t want to talk about C#’s approach to how it handles modules and the differences of it’s language features in comparison to C++, don’t bring it up in the first place.
On Tue, Feb 12, 2019 at 12:13, Gabriel Dos Reis <gdr_at_[hidden]<mailto:gdr_at_[hidden]>> wrote:
* If each implementation does something different regarding modules and filenames, then C++ will die a slow painful death.
Drama effects aside, remember that I was the one who called for the creation of this SG so that implementers and tools builders can discuss issues like this and come to agreement on common tasks and notations.
* I do not trust vendors to do the right thing and work together outside of the standard.
I suppose that would mean I give implementers more credit than you do. Maybe it is because I’m close to them and I can be accused of bias, or something. If you don’t trust them to do the right thing, why would you trust them to implement the Standard at all or if they do they implement it in a way that is useful?
* Furthermore, while C# permits names and modules not being the same, this isn't as much of an issue given that a module is also a namespace
That has zero relevance as to what the problem is.
From: tooling-bounces_at_[hidden]<mailto:tooling-bounces_at_[hidden]> <tooling-bounces_at_[hidden]<mailto:tooling-bounces_at_[hidden]>> On Behalf Of Isabella Muerte
Sent: Sunday, February 3, 2019 8:01 PM
To: WG21 Tooling Study Group SG15 <tooling_at_[hidden]<mailto:tooling_at_[hidden]>>
Subject: Re: [Tooling] SG15 Why do we need module name to file name mapping
If each implementation does something different regarding modules and filenames, then C++ will die a slow painful death. If we can't have implementations agree on a singular thing to do, that is going to fragment the community further, cause headaches, and waste hundreds of hours of developer time trying to get everything to work the same. I do not trust vendors to do the right thing and work together outside of the standard.
Furthermore, while C# permits names and modules not being the same, this isn't as much of an issue given that a module is also a namespace (which is orthogonal to modules in C++), they have partial classes (which we do not), and they don't have separate interface and implementation files. I reckon if C# had to deal with some of the issues we are, it would be less popular. 😉
‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Sunday, February 3, 2019 7:41 PM, Gabriel Dos Reis <gdr_at_[hidden]<mailto:gdr_at_[hidden]>> wrote:
* We have a lot of experience in other languages for deterministic and direct name -> file mapping, very little for having the module name solely in the source.
I keep reading this. The opposite is just true as well. For example, there are lot of experience with C# out there and their productivity hasn’t gotten down because of it.
Lost in all this brouhaha is the fact that the IS does not preclude a trivial mapping: your implementation will document what it wants.
From: tooling-bounces_at_[hidden]<mailto:tooling-bounces_at_[hidden]> <tooling-bounces_at_[hidden]<mailto:tooling-bounces_at_[hidden]>> On Behalf Of Corentin
Sent: Sunday, February 3, 2019 6:00 PM
To: WG21 Tooling Study Group SG15 <tooling_at_[hidden]<mailto:tooling_at_[hidden]>>
Subject: Re: [Tooling] SG15 Why do we need module name to file name mapping
We don't need it and a lot of us believe we need to not have it.
The price for this level of indirection, as you say is quite high on tooling. the benefits un-existant.
The evolution working group and the authors of the module proposal seem afraid to over specify - while SG-15 thinks
leaving things as they are will lead for decades of pain. At least, I certainly think so.
We have a lot of experience in other languages for deterministic and direct name -> file mapping, very little for having the module name solely in the source.
As for name collision... It's not a problem. It would even be a good thing to make sure not to have duplicated file names:
Module identifier needs to be unique in a program, so asking the same of files is reasonable.
On Mon, 4 Feb 2019 at 02:20 Scott Wardle <swardle_at_[hidden]<mailto:swardle_at_[hidden]>> wrote:
Hi all,
I have been looking for some information why do we need a level of indirection from module name to module interface file name. Why are modules names need a different system then header names.
I have hear that Microsoft was having some problems with name collision. Is there more concrete information about the problem that Microsoft or other companies were having?
If you have a name collision today with headers we would just make another library that wraps one of the two colliding headers. I name the public header of this new library something different and problem solved.
So I don’t understand why are we paying for this level of indirection but I probably just don’t understand the problem.
Scott
_______________________________________________
Tooling mailing list
Tooling_at_[hidden]<mailto:Tooling_at_[hidden]>
http://www.open-std.org/mailman/listinfo/tooling<https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.open-std.org%2Fmailman%2Flistinfo%2Ftooling&data=02%7C01%7Cgdr%40microsoft.com%7C4a4968c702c846b48a7e08d6912d0707%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636856019956909342&sdata=NOin28FVjhSYBlX7%2FYhdqZZ6lmWbBtO6AVzXTiN4f7o%3D&reserved=0>
The very first time it had a chance to meet?
Your contributions are very much appreciated and not being diminished in any way by anyone.
* If you didn’t want to talk about C#’s approach to how it handles modules and the differences of it’s language features in comparison to C++, don’t bring it up in the first place.
You misunderstood the statement. What was meant is that the fact that namespaces are module names is irrelevant to the mapping problem.
From: Isabella Muerte <imuerte_at_[hidden]>
Sent: Tuesday, February 12, 2019 1:00 PM
To: Gabriel Dos Reis <gdr_at_[hidden]>; WG21 Tooling Study Group SG15 <tooling_at_[hidden]>
Subject: Re: RE: [Tooling] SG15 Why do we need module name to file name mapping
And it took how long after it’s formation for anyone except me to raise their hand and their concerns for modules tooling? How many ISO meetings before we could even agree on what it’s goal and direction was? Color me unimpressed with the effort of SG15 until very recently.
I do not trust implementors to do the right thing because y’all have shown yourselves incapable of it until recently. You have maybe 5 years of doing the right thing (and that’s generous) backed by 15 years of doing the wrong thing or making false claims like “we’re C++ compliant!” when their library is lacking interfaces for compliance or language features that are required. How many years did it take for us to get all the keywords required by the standard to be enabled by default in msvc without including a header that is supposed to be empty? I do not mistrust out of doubt, but out of experience with three separate implementations.
This and the previous dismissal of my statement is why so many people are concerned about modules. You deflect and move goal posts as is convenient, and this is why we are for the large part dissatisfied with modules as specified. If you didn’t want to talk about C#’s approach to how it handles modules and the differences of it’s language features in comparison to C++, don’t bring it up in the first place.
On Tue, Feb 12, 2019 at 12:13, Gabriel Dos Reis <gdr_at_[hidden]<mailto:gdr_at_[hidden]>> wrote:
* If each implementation does something different regarding modules and filenames, then C++ will die a slow painful death.
Drama effects aside, remember that I was the one who called for the creation of this SG so that implementers and tools builders can discuss issues like this and come to agreement on common tasks and notations.
* I do not trust vendors to do the right thing and work together outside of the standard.
I suppose that would mean I give implementers more credit than you do. Maybe it is because I’m close to them and I can be accused of bias, or something. If you don’t trust them to do the right thing, why would you trust them to implement the Standard at all or if they do they implement it in a way that is useful?
* Furthermore, while C# permits names and modules not being the same, this isn't as much of an issue given that a module is also a namespace
That has zero relevance as to what the problem is.
From: tooling-bounces_at_[hidden]<mailto:tooling-bounces_at_[hidden]> <tooling-bounces_at_[hidden]<mailto:tooling-bounces_at_[hidden]>> On Behalf Of Isabella Muerte
Sent: Sunday, February 3, 2019 8:01 PM
To: WG21 Tooling Study Group SG15 <tooling_at_[hidden]<mailto:tooling_at_[hidden]>>
Subject: Re: [Tooling] SG15 Why do we need module name to file name mapping
If each implementation does something different regarding modules and filenames, then C++ will die a slow painful death. If we can't have implementations agree on a singular thing to do, that is going to fragment the community further, cause headaches, and waste hundreds of hours of developer time trying to get everything to work the same. I do not trust vendors to do the right thing and work together outside of the standard.
Furthermore, while C# permits names and modules not being the same, this isn't as much of an issue given that a module is also a namespace (which is orthogonal to modules in C++), they have partial classes (which we do not), and they don't have separate interface and implementation files. I reckon if C# had to deal with some of the issues we are, it would be less popular. 😉
‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Sunday, February 3, 2019 7:41 PM, Gabriel Dos Reis <gdr_at_[hidden]<mailto:gdr_at_[hidden]>> wrote:
* We have a lot of experience in other languages for deterministic and direct name -> file mapping, very little for having the module name solely in the source.
I keep reading this. The opposite is just true as well. For example, there are lot of experience with C# out there and their productivity hasn’t gotten down because of it.
Lost in all this brouhaha is the fact that the IS does not preclude a trivial mapping: your implementation will document what it wants.
From: tooling-bounces_at_[hidden]<mailto:tooling-bounces_at_[hidden]> <tooling-bounces_at_[hidden]<mailto:tooling-bounces_at_[hidden]>> On Behalf Of Corentin
Sent: Sunday, February 3, 2019 6:00 PM
To: WG21 Tooling Study Group SG15 <tooling_at_[hidden]<mailto:tooling_at_[hidden]>>
Subject: Re: [Tooling] SG15 Why do we need module name to file name mapping
We don't need it and a lot of us believe we need to not have it.
The price for this level of indirection, as you say is quite high on tooling. the benefits un-existant.
The evolution working group and the authors of the module proposal seem afraid to over specify - while SG-15 thinks
leaving things as they are will lead for decades of pain. At least, I certainly think so.
We have a lot of experience in other languages for deterministic and direct name -> file mapping, very little for having the module name solely in the source.
As for name collision... It's not a problem. It would even be a good thing to make sure not to have duplicated file names:
Module identifier needs to be unique in a program, so asking the same of files is reasonable.
On Mon, 4 Feb 2019 at 02:20 Scott Wardle <swardle_at_[hidden]<mailto:swardle_at_[hidden]>> wrote:
Hi all,
I have been looking for some information why do we need a level of indirection from module name to module interface file name. Why are modules names need a different system then header names.
I have hear that Microsoft was having some problems with name collision. Is there more concrete information about the problem that Microsoft or other companies were having?
If you have a name collision today with headers we would just make another library that wraps one of the two colliding headers. I name the public header of this new library something different and problem solved.
So I don’t understand why are we paying for this level of indirection but I probably just don’t understand the problem.
Scott
_______________________________________________
Tooling mailing list
Tooling_at_[hidden]<mailto:Tooling_at_[hidden]>
http://www.open-std.org/mailman/listinfo/tooling<https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.open-std.org%2Fmailman%2Flistinfo%2Ftooling&data=02%7C01%7Cgdr%40microsoft.com%7C4a4968c702c846b48a7e08d6912d0707%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636856019956909342&sdata=NOin28FVjhSYBlX7%2FYhdqZZ6lmWbBtO6AVzXTiN4f7o%3D&reserved=0>
Received on 2019-02-12 22:06:03