Date: Fri, 10 May 2019 16:54:50 +0000
Attendees:
Ben Craig
Ben Boeckel
Gaby Dos Reis
JF Bastien
Luasz Menakiewicz
Mark Zeren
Nathan Sidwell
Olgaark (Microsoft)
Tom Honermann
Corentin Jabot
Blaikie
Richard Smith
Presenting https://isocpp.org/files/papers/D1634R0.html
Tom: What's the status quo on if we have a conflict?
Nathan: Ill-formed, only when you try to import the wrong one
Corentin: Build system can give diagnostics if you have two modules with the same name in the same dependency graph
GDR: You can have conflicts within an organization
Nathan: We also have this collision problem with namespaces. That doesn't seem to be a problem that requires vendor specific namespaces. Why do we thing this will be a bigger problem with modules?
Boeckel: One thing we do with our third party packages is mangle the packages. We change the names of the shared library and of the dynamic symbols.
Nathan: There must be some subtleties there
Tom Honermann: Namespaces merge naturally
Ben Craig: You need a double colision (namespace and class names)
Mark Zeren: These collisons are a problem. Google allegedly has a registry for top level namespaces. VMWare probably needs one.
Sidwell: Would like to see that kind of rationale in the paper, to illustrate that it is a problem.
Tom: When we import a module, we need the unique file that corresponds to the module
Gaby: Difference is that with namespaces, we get collision of members, and it can be subtle.
>From ben.boeckel to Everyone: 11:15 AM
https://github.com/mathstuf/cxx-modules-sandbox/blob/master/link-use-mask/CMakeLists.txt
Nathan: There seem to be some mitigating strategies today, but we aren't describing today's mitigations. Why don't we already hit this problem with existing software.
On most CPP projects, the dependency tree is shallow, so they mostly conflict with themself. At the namespace level, most projects use namespaces as a way to scope names. With headers you can rename the headers on disk to solve some uniquification problems.
Two libraries (simple and duplicate) which have a module m. Two executables that import m. First one found is it. Cmake could say that it sees two "m"s and error out. Only works when the same name module is visible in the same place. Two libraries that make a config module way down deep, that is going to be harder to diagnose.
Tom: Please switch from ASCII to basic source character set
Corentin: Would be nice to have a way to map module names to file names at some point, and we are limited in what we can put in a file name. Limiting ourself to the basic character set helps that. We can also avoid some issues if we stick with lower case, particularly when sharing between Windows and Linux.
Gaby: Other languages have a mix of pascal case vs. lower case. I would like to be able to visually seperate module names from namespace names, which would argue for pascal case. I'm not sure if we want to force it, or if this is just a guideline.
Corentin: There is no enforcement, no language changes.
Gaby: For the TR, we are aiming for something that everyone would be using and doing. My organization is using a different scheme already, and I would like to avoid that if possible.
Tom: Are they different just because of the casing, or are they using characters outside of the basic character set?
Gaby: Just casing
JF: ASCII seems like an overly protective regression.
JF: I think we should try to fix some of the existing identifiers with unicode. We should fix C++ as a whole, and make modules follow that. I don't think we should race to the bottom and support only the lowest common denominator. We don't want to go back to the 8 character file length. Accept that on some file systems, the mapping will be difficult. What do git and SVN do
Gaby: Agree. Misconceptions on Windows. Don't want to base what we are doing on Windows misconceptions.
JF: We should guide people to names that don't clash.
Tom: I would not like to limit to ascii either. Would like to give an algorithm to let tools implement the mapping
Corentin: Underlying filename, you can't rename it. You need to have the same mapping on each platform. Because of that, I think we should have a subset of characters. It's about understanding the filename and make sure that tools like cmake will be able to find and name the BMI appropriately.
Tom: Not sure why the source filename needs to be renamed. Doesn't need to be a correlation between bmi, source, and object name.
Corentin: Would like to make it possible to have a mapping between the module name and a source file name.
>From blaikie to Everyone: 11:34 AM
The compiler/build system could implement a name->filesystem name mapping if the filesystem has naming limitations.
Tom: Would be useful to implement a mapping algorithm (note taker: like punicode)
Ben: Is there an expectation that if you have a foo.bar, that you also have a foo?
Corentin: No. If you have `google.abseil`, you don't need `google`. If you google.abseil.list, then google.abseil should also bring google.abseil.list.
Gaby: This has problems at scale. I could have a subgroup that conflicts with the bigger group. This introduces problems.
Tom: Should be with something like MISRA, and not the TR.
Corentin: We want this to make it easier to do dependency management at scale. Can't have name conflicts, as the whole world is your dependency graph. If you have a module name, you could have a global index of every module name that exists, and find the library / project where it is declared and automatically download that library.
Gaby: If you want the library downloaded with no input, then yes. In practice, you want input from the user. It's ok to have several repos competing to provide something and you have to choose them.
Corentin: If you have two third party libraries that both import a library named foo that you have a conflict that you have no control over. This is one of the reasons you need unique names. The number of dependencies you have can grow exponentially. It needs to not happen to begin with.
>From blaikie to Everyone: 11:48 AM
Even with unique module names - you still have the version problem. Your dependency A depends on X1, but dependency B depends on X2.
>From JF Bastien to Everyone: 11:50 AM
Did someone say "semantic versioning" yet? Because my BINGO card has it.
>From ben.boeckel to Everyone: 11:51 AM
symbol versioning on there too?
Gaby: You get to choose in practice, because if you don't, you are in big trouble. There are things like licences that users have to pick.
Corentin: Renaming a module is a major breaking change
Ben Craig
Ben Boeckel
Gaby Dos Reis
JF Bastien
Luasz Menakiewicz
Mark Zeren
Nathan Sidwell
Olgaark (Microsoft)
Tom Honermann
Corentin Jabot
Blaikie
Richard Smith
Presenting https://isocpp.org/files/papers/D1634R0.html
Tom: What's the status quo on if we have a conflict?
Nathan: Ill-formed, only when you try to import the wrong one
Corentin: Build system can give diagnostics if you have two modules with the same name in the same dependency graph
GDR: You can have conflicts within an organization
Nathan: We also have this collision problem with namespaces. That doesn't seem to be a problem that requires vendor specific namespaces. Why do we thing this will be a bigger problem with modules?
Boeckel: One thing we do with our third party packages is mangle the packages. We change the names of the shared library and of the dynamic symbols.
Nathan: There must be some subtleties there
Tom Honermann: Namespaces merge naturally
Ben Craig: You need a double colision (namespace and class names)
Mark Zeren: These collisons are a problem. Google allegedly has a registry for top level namespaces. VMWare probably needs one.
Sidwell: Would like to see that kind of rationale in the paper, to illustrate that it is a problem.
Tom: When we import a module, we need the unique file that corresponds to the module
Gaby: Difference is that with namespaces, we get collision of members, and it can be subtle.
>From ben.boeckel to Everyone: 11:15 AM
https://github.com/mathstuf/cxx-modules-sandbox/blob/master/link-use-mask/CMakeLists.txt
Nathan: There seem to be some mitigating strategies today, but we aren't describing today's mitigations. Why don't we already hit this problem with existing software.
On most CPP projects, the dependency tree is shallow, so they mostly conflict with themself. At the namespace level, most projects use namespaces as a way to scope names. With headers you can rename the headers on disk to solve some uniquification problems.
Two libraries (simple and duplicate) which have a module m. Two executables that import m. First one found is it. Cmake could say that it sees two "m"s and error out. Only works when the same name module is visible in the same place. Two libraries that make a config module way down deep, that is going to be harder to diagnose.
Tom: Please switch from ASCII to basic source character set
Corentin: Would be nice to have a way to map module names to file names at some point, and we are limited in what we can put in a file name. Limiting ourself to the basic character set helps that. We can also avoid some issues if we stick with lower case, particularly when sharing between Windows and Linux.
Gaby: Other languages have a mix of pascal case vs. lower case. I would like to be able to visually seperate module names from namespace names, which would argue for pascal case. I'm not sure if we want to force it, or if this is just a guideline.
Corentin: There is no enforcement, no language changes.
Gaby: For the TR, we are aiming for something that everyone would be using and doing. My organization is using a different scheme already, and I would like to avoid that if possible.
Tom: Are they different just because of the casing, or are they using characters outside of the basic character set?
Gaby: Just casing
JF: ASCII seems like an overly protective regression.
JF: I think we should try to fix some of the existing identifiers with unicode. We should fix C++ as a whole, and make modules follow that. I don't think we should race to the bottom and support only the lowest common denominator. We don't want to go back to the 8 character file length. Accept that on some file systems, the mapping will be difficult. What do git and SVN do
Gaby: Agree. Misconceptions on Windows. Don't want to base what we are doing on Windows misconceptions.
JF: We should guide people to names that don't clash.
Tom: I would not like to limit to ascii either. Would like to give an algorithm to let tools implement the mapping
Corentin: Underlying filename, you can't rename it. You need to have the same mapping on each platform. Because of that, I think we should have a subset of characters. It's about understanding the filename and make sure that tools like cmake will be able to find and name the BMI appropriately.
Tom: Not sure why the source filename needs to be renamed. Doesn't need to be a correlation between bmi, source, and object name.
Corentin: Would like to make it possible to have a mapping between the module name and a source file name.
>From blaikie to Everyone: 11:34 AM
The compiler/build system could implement a name->filesystem name mapping if the filesystem has naming limitations.
Tom: Would be useful to implement a mapping algorithm (note taker: like punicode)
Ben: Is there an expectation that if you have a foo.bar, that you also have a foo?
Corentin: No. If you have `google.abseil`, you don't need `google`. If you google.abseil.list, then google.abseil should also bring google.abseil.list.
Gaby: This has problems at scale. I could have a subgroup that conflicts with the bigger group. This introduces problems.
Tom: Should be with something like MISRA, and not the TR.
Corentin: We want this to make it easier to do dependency management at scale. Can't have name conflicts, as the whole world is your dependency graph. If you have a module name, you could have a global index of every module name that exists, and find the library / project where it is declared and automatically download that library.
Gaby: If you want the library downloaded with no input, then yes. In practice, you want input from the user. It's ok to have several repos competing to provide something and you have to choose them.
Corentin: If you have two third party libraries that both import a library named foo that you have a conflict that you have no control over. This is one of the reasons you need unique names. The number of dependencies you have can grow exponentially. It needs to not happen to begin with.
>From blaikie to Everyone: 11:48 AM
Even with unique module names - you still have the version problem. Your dependency A depends on X1, but dependency B depends on X2.
>From JF Bastien to Everyone: 11:50 AM
Did someone say "semantic versioning" yet? Because my BINGO card has it.
>From ben.boeckel to Everyone: 11:51 AM
symbol versioning on there too?
Gaby: You get to choose in practice, because if you don't, you are in big trouble. There are things like licences that users have to pick.
Corentin: Renaming a module is a major breaking change
Received on 2019-05-10 20:08:18