https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120676
--- Comment #4 from Nathaniel Shead <nshead at gcc dot gnu.org> --- (In reply to Larry Smith from comment #3) > Thanks for the feedback. Will take a look into the "Textual merging of > reachable GM entities" issue you mentioned. The > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114990 bug you referred to > however (that I posted last year) was repaired in 15.1, but the new bug > posted here (in the thread we're now discussing) is still present of course, > though "almost exactly" the same you said so I'll look into the "Textual > merging" issue to see if I can circumvent it. I'm somewhat surprised actually that 114990 is working now, but in GCC15 we fixed some issues with too much being emitted in the module CMI so that may have hidden the issue. (Feel free to close the PR if it's no longer relevant though; I'm currently using 99000 as the dup target for all these kinds of bugs regardless.) > As for your take on the lack of interest in GCC's module support (though I > know this is completely off-topic), if true then it's surprising (assuming > you're referring to GCC's module support in general, and not specifically to > its availability in some relatively unknown OSS like my own). I know very > little about GCC and the political culture behind it (the forces driving > which new features in the standard get priority), but I would think (maybe > naively) that after almost 5 years since the C++20 standard came out, > there'd be a desire to complete the implementation of modules and eliminate > these lingering issues (and I'm sure there must be - a lot of hard work has > already gone into it, if you're one of the developers you have my thanks :) You're right that there's desire, but the reality is that there's a lot of things to do and very few people to do it. The original developer of modules in GCC hasn't been active for a while now. Jason Merrill and Patrick Palka have been very helpful but both appear to be working on lots of other things. Instead, I've been working on modules as a "spare time" project for the last year and a half or so, and like to think I've made some good progress given those constraints, but ultimately my "real" job and responsibilities have to take precedence! (Part of the issue has also always been a lack of bug reports: we know support is incomplete, but apart from a couple of major features and a bunch of super minor issues I haven't had a chance to work on yet I don't know what bugs are left. So thank you again for giving the support a spin and reporting any problems you find!) > My own OSS library likely targets a niche audience in reality, and almost > all users will likely be using the ".h" version anyway, so the module > version isn't critical for me personally, so truth is I'm actually not > holding my breath as you said (though the library does close a gap in the > C++ standard, providing a complete family of traits for tearing apart C++ > function types, but the module version is just a "nice-to-have" feature for > now). It does compile in Clang and MSVC however so making it work in the > last of the "big 3" compilers is something I'd like to see completed (though > that's not GCC's concern of course). > > As a final side-note, there is a general expectation by C++ developers > (maybe not always realistic) that when a new standard feature comes out, the > major compiler vendors normally make an effort to implement them ASAP. GCC > does advertise that modules are "not complete" yet, and I recognize that > modules is a pretty significant chunk of work to say the least (!), but > given the well-known headaches of ".h" files since the inception of C > itself, modules significantly improve the situation. Its usage should be > (strongly) encouraged IMHO and to that end all the major compiler vendors > should do their best to complete the implementation ASAP (and I do know > they're trying - a lot of work required for this feature and it's recognized > and appreciated by developers like myself). Resources and $ are always going > to be in the way of course, but given the pressure C++ is now under from the > U.S. gov't and the longer term (potential) threat of new languages like > Rust, one would hope there'd be a drive to start moving towards modules for > the next generation of C++ developers (to make the language more appealing > and keep C++ relevant into the future). > > Anyway, thanks again for the feedback (appreciated). But yeah, the issue is more that there aren't enough resources in general, and although modules are definitely nice to have, people are also clamouring for improved support on... lots of other things. So unless funding (or I guess more pertinently, people) materialise, slow and steady will have to be the way to go.
