Date: Thu, 13 Oct 2022 09:33:40 +0000
Really, "importable" is a description of *use* rather than an intrinsic state. Even a messy header file can turn can "be importable" with the right set of macro defines, etc.
For all useful purposes, all the compiler has to do is accept producing a BMI when asked, and then document the conditions under which production and imports of such things work. A crude practical documentation that an implementation can offer is "If I can produce a BMI and the import works, then the header file is importable."
Header units were invented as a way to speed up header file inclusion for existing headers that were written before modules were introduced in C++. Implicit in that assumption is that we can't go back and ask people to modify those headers. So, requiring an in-source thing to mark them defeats the purpose.
I would suggest that we focus on use, as opposed to trying to categorize intrinsic state. The proof of the pudding is in the eating... 😊
-- Gaby
________________________________
From: SG15 <sg15-bounces_at_[hidden]> on behalf of Iain Sandoe via SG15 <sg15_at_[hidden]>
Sent: Thursday, October 13, 2022 1:41:27 AM
To: SG15_at_[hidden] <SG15_at_[hidden]>
Cc: Iain Sandoe <iain_at_[hidden]>
Subject: [SG15] Header units again.
Hello SG15,
Sadly the Friday meeting time is not one I can make usually, so email for now…
---
Once again in the course of implementation work we find ourselves noticing that Header Units are special.
* The compiler cannot determine from the source that a header is an importable one.
* AFAICT, the build system can figure that a source depends on a specific header, but it is also not able to determine if that header is an “importable” one (except for the sub-set that are pre-defined to be). Which means that we probably require that the user’s project defines which headers are importable. That disconnects metadata from the sources which is undesirable, if not a recipe for bugs.
I expect that this has been discussed before, and I’ve missed it somehow .. but several times during my implementation work on clang, it seemed to me that this problem would go away if importable header units were required to start with a keyword.
The first idea that occurred would be to have them start with “module;” which matches the logical behaviour (the entire content is in the GMF). However, since we already have compiler diagnostics about ‘module;’ without a following ‘module XXX;’ that would presumably not work easily now.
Suppose we chose to require that they start with “header-unit;”?
it is
* simple,
* unlikely to clash with any other keyword intent
* not an invasive source change
* fast to parse for build systems and compilers alike.
Given an expectation that the user has to identify importable header units somehow, doing it in the source seems to me to be the neatest solution.
what did I miss?
Iain
P.S I was considering making this an NB comment - but feedback would be welcome.
_______________________________________________
SG15 mailing list
SG15_at_lists.isocpp.org
https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.isocpp.org%2Fmailman%2Flistinfo.cgi%2Fsg15&data=05%7C01%7Cgdr%40microsoft.com%7C71442da7a0484e8c0c0c08daacf6bb26%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638012472965810801%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=8P9fGRw3t2YfqHEADyEyYn0lcYvWzovuuxW26Pj3f9w%3D&reserved=0
For all useful purposes, all the compiler has to do is accept producing a BMI when asked, and then document the conditions under which production and imports of such things work. A crude practical documentation that an implementation can offer is "If I can produce a BMI and the import works, then the header file is importable."
Header units were invented as a way to speed up header file inclusion for existing headers that were written before modules were introduced in C++. Implicit in that assumption is that we can't go back and ask people to modify those headers. So, requiring an in-source thing to mark them defeats the purpose.
I would suggest that we focus on use, as opposed to trying to categorize intrinsic state. The proof of the pudding is in the eating... 😊
-- Gaby
________________________________
From: SG15 <sg15-bounces_at_[hidden]> on behalf of Iain Sandoe via SG15 <sg15_at_[hidden]>
Sent: Thursday, October 13, 2022 1:41:27 AM
To: SG15_at_[hidden] <SG15_at_[hidden]>
Cc: Iain Sandoe <iain_at_[hidden]>
Subject: [SG15] Header units again.
Hello SG15,
Sadly the Friday meeting time is not one I can make usually, so email for now…
---
Once again in the course of implementation work we find ourselves noticing that Header Units are special.
* The compiler cannot determine from the source that a header is an importable one.
* AFAICT, the build system can figure that a source depends on a specific header, but it is also not able to determine if that header is an “importable” one (except for the sub-set that are pre-defined to be). Which means that we probably require that the user’s project defines which headers are importable. That disconnects metadata from the sources which is undesirable, if not a recipe for bugs.
I expect that this has been discussed before, and I’ve missed it somehow .. but several times during my implementation work on clang, it seemed to me that this problem would go away if importable header units were required to start with a keyword.
The first idea that occurred would be to have them start with “module;” which matches the logical behaviour (the entire content is in the GMF). However, since we already have compiler diagnostics about ‘module;’ without a following ‘module XXX;’ that would presumably not work easily now.
Suppose we chose to require that they start with “header-unit;”?
it is
* simple,
* unlikely to clash with any other keyword intent
* not an invasive source change
* fast to parse for build systems and compilers alike.
Given an expectation that the user has to identify importable header units somehow, doing it in the source seems to me to be the neatest solution.
what did I miss?
Iain
P.S I was considering making this an NB comment - but feedback would be welcome.
_______________________________________________
SG15 mailing list
SG15_at_lists.isocpp.org
https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.isocpp.org%2Fmailman%2Flistinfo.cgi%2Fsg15&data=05%7C01%7Cgdr%40microsoft.com%7C71442da7a0484e8c0c0c08daacf6bb26%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638012472965810801%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=8P9fGRw3t2YfqHEADyEyYn0lcYvWzovuuxW26Pj3f9w%3D&reserved=0
Received on 2022-10-13 09:33:43