Date: Thu, 13 Oct 2022 19:52:00 +0200
Is it though?
A header is importable if it isn't affected by the state of the
preprocessor (or all headers in a project are designed to be used with the
same preprocessor state).
I think we would find that the vast, vast majority of headers are
importable, so the focus should be on those that are not.
https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p1905r0.pdf
proposed an in-source mechanism to do that (as i generally agree that
source files should not overly rely on external information to be usable),
but at the very least, build systems should provide an "all my headers are
importable" option.
On Thu, Oct 13, 2022 at 11:45 AM Iain Sandoe via SG15 <sg15_at_[hidden]>
wrote:
> Hi Gaby, SG15,
>
> I consider my question answered :)
> .. and there is no point in pursuing this idea,
>
> thanks
> Iain
>
> > On 13 Oct 2022, at 10:33, Gabriel Dos Reis <gdr_at_[hidden]> wrote:
> >
> > 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_[hidden]
> >
> 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
>
> _______________________________________________
> SG15 mailing list
> SG15_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/sg15
>
A header is importable if it isn't affected by the state of the
preprocessor (or all headers in a project are designed to be used with the
same preprocessor state).
I think we would find that the vast, vast majority of headers are
importable, so the focus should be on those that are not.
https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p1905r0.pdf
proposed an in-source mechanism to do that (as i generally agree that
source files should not overly rely on external information to be usable),
but at the very least, build systems should provide an "all my headers are
importable" option.
On Thu, Oct 13, 2022 at 11:45 AM Iain Sandoe via SG15 <sg15_at_[hidden]>
wrote:
> Hi Gaby, SG15,
>
> I consider my question answered :)
> .. and there is no point in pursuing this idea,
>
> thanks
> Iain
>
> > On 13 Oct 2022, at 10:33, Gabriel Dos Reis <gdr_at_[hidden]> wrote:
> >
> > 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_[hidden]
> >
> 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
>
> _______________________________________________
> SG15 mailing list
> SG15_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/sg15
>
Received on 2022-10-13 17:52:14