On Mon, 4 Feb 2019 at 05:01 Isabella Muerte <imuerte_at_[hidden]> wrote:

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

+1

Also, when you say "your implementation" that's a very fuzzy thing when
talking about modules.
There is a build system, a compiler, a package manager, multiple tools and
they all need to agree on the same conventions for anything to work.

One of C++ strength is to be portable across a wide variety of systems.
Alas, tools are not portable and often not compatible.

Lack of common ground rules is what makes consuming libraries and reusing
code in C++
time-consuming (and therefore costly).
There is nothing in the language per-say that precludes good dependency
management,
but because every vendor has to come up with their own solutions to the
same problems,
everybody needs to support non-standard, slightly broken behaviors.

I agree that in general, most of the challenges that tool face fall outside
of the scope of the IS.
In this particular case, however, it doesn't seem difficult to set these
rules.

And, there would be no loss in expressiveness.
Indeed, what is the added value of not requiring some deterministic mapping?
What do I gain in having "export module foo" in a resource identified by
bar?

(Note that we do not want module interface units to be necessarily files
just that they be identified by the name of the module they define)

Freedom of implementation only makes sense if the added value it provides
is greater than its cost.
Ecosystems need rules to thrive.

Sure, ultimately people would probably find workarounds and hack and build
systems would support multiple compiler implementations.
At what cost? In how many years?




> 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]>
> 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] <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]>
> *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]> 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]
> 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%7C3adf39f0c683427fb84108d68a447a81%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636848424056005598&sdata=NzK37Ir7HzGpduYGXcUZtsC5u8N0DzOVxpdWUnIsIU0%3D&reserved=0>
>
>
> _______________________________________________
> Tooling mailing list
> Tooling_at_[hidden]
> http://www.open-std.org/mailman/listinfo/tooling
>