Daniel: Not an expert on the subject, I should be reluctant to reply on list, except that 24 hours have passed and I see no other replies on list yet; so here goes. On Thu, Nov 04, 2021 at 04:03:31PM -0400, Daniel Ruoso wrote: > During early discussion in the SG15 mailing list[3], it became clear > that some folks are interested in getting a bit further in the package > management side. During cppcon last week I managed to sit down with > some of those folks, and got to an agreement to explore the > possibility of moving the C++ language a bit ahead in the package > management space, instead of just "accepting defeat" and making > modules behave like headers in the way they are distributed. I did not know that to make modules behave like headers were to accept defeat! Is it? I had thought that *the original idea* was to make modules indeed behave like headers, except without bringing the preprocessor into it. Someone has probably asked such questions on your committee a long time ago, but I was not there, so may I ask: what would the drawback be in letting modules behave like headers at least for now, and then revisiting the question for C++26 or C++29 in view of accumulated experience? The answer to the last question is unclear to me from your papers. It has something to do with Bloomberg and monorepo (the last being a word I had to go to look up). I didn't get it, to tell the truth. Another way to ask the question is: wouldn't you rather implement something like your paper [2] for now, and then gradually expand upon that later to move cautiously in the direction of paper [1]? Or am I missing the point? > [1]: https://isocpp.org/files/papers/P2409R0.pdf - Although it is > written from Bloomberg's perspective, our understanding is that it > matches the requirements for most distributions (in fact, bloomberg > uses dpkg for its internal libraries deployed as a "partial > distribution" into /opt/bb) > [2]: https://isocpp.org/files/papers/P2473R0.pdf - This is a "let's > make modules look like headers" proposal. Except for the part on discovery tooling, which admittedly looks to me as though it might be slightly overengineered for C++23, paper [2] looks pretty good to me at first glance. (Admittedly, this may be merely because I understand paper [2] but do not understand paper [1].) So here is an alternate, tangential question which gets in a roundabout way at the same point, if you wish: if your more advanced proposals such as in paper [1] were implemented, then what would happen to the preprocessor? Admittedly, I have not directly used the preprocessor to do anything interesting since the C++98/03 era, but the thought of eliminating the preprocessor entirely seems unsettlingly un-C++-like to me. Doesn't it, to you, too? Or am I again missing the point? Meanwhile, it occurs to me that, in Debian, C++20 has only reached sid a few months ago; and even then, to the extent to which GCC is used, the compiler falls back to C++17 unless explicitly asked not to; so it could be that there exists limited practical experience in the Debian Project *at this time* to treat with you on questions like the questions you are asking regarding C++ modules. I am glad that you are asking the questions, nevertheless.
Attachment:
signature.asc
Description: PGP signature