Hacker News Reader

Comment by pjmlp | Hacker News Reader

Ideally, anything past C++20 should be made available as module as well.

Ideally, modules should first of all be implemented fully according to the standard - CMake does not support gcc13 (14 isn't released yet), MSVC spits internal compiler errors when mixing #includes with imports, VS IntelliSense is buggy, clangd has no modules support whatsoever.

There's barely a point in supporting moduleso sfar unless you really enjoy pain.

Modules are mostly usable on VS 2020/MSBuild and clang 17/CMake 3.28.

If we don't try to use them, we cannot complain they don't get used, someone has to submit bug reports.

Again, they are barely functional.

MSVC chokes on many standard-defined constructs: https://github.com/microsoft/STL/issues/1694

clang does not claim to be "mostly usable" at all - most papers are not implemented: https://clang.llvm.org/cxx_status.html#cxx20

And gcc will only start ot be usable with CMake when version 14 is released - that has not happened yet.

And, as I mentioned before, IDE support is either buggy (Visual Studio) or non-existing (any other IDE/OS). So you're off to writing in a text editor and hoping your compiler works to a somewhat usable degree. Yes, at some point people should start using modules, I agree, but to advise library maintainers to ship modularized code... the tooling just isn't there yet.

I mean, the GitHub issue is Microsoft trying to ship their standard library modularized, they employ some of the most capable folks on the planet and pay them big money to get that done, while metaphorically sitting next to the Microsoft compiler devs, and they barely, barely get it done (with bugs, as they themselves mention). This is too much for most other library maintainers.

Again, see my Github, using exclusively C++ modules for quite some time.

Someone has to actually try to use modules and report bugs.

Not every library has to work in all compilers of the world.

> Ideally, anything past C++20 should be made available as module as well.

> Not every library has to work in all compilers of the world.

These two statements directly contradict each other. It's great that you are in a space where you can use modules, but most other people are not, and expecting them to ship modularized versions of their libraries is inconsiderate given the limitations they face.

I started my comment with "Ideally," which as per Oxford dictionary gets me:

- perfectly; in the most suitable way

- in an imagined way; in a way that is not likely to happen or be real

Choosing not to sympathize with the reality of most C++ devs is up to you, you've made it very clear that you refuse to acknowledge my point. No need to get snarky.

It is not me that lacks understating of what "Ideally,.." and "as well" means in practice, hint it is a OR, not a XOR.

Well, you certainly lack the imagination of working with given constraints outside of your bubble, so I guess we've both learned something today.

Agree, but I don't have enough experience yet with modules (I find them confusing). Maybe for later, PRs are welcome :)

Sure, expect something, at least for VC++.

I know you're an expert, and maybe not wrong. But every couple of months I try out the state of modules. And I didn't get even remotely close to a point where I would consider them ready. Always the most bleeding edge preview version of VS

I won't deny that there aren't issues with them, still if we don't use and complain about what is still not there, they won't get better.

We already moved beyond a state where nothing really worked, to at very least being able to write CLI stuff using import std and our own libraries, alongside module fragments.

I have a couple of hobby projects on Github using modules.

fair enough. I'll dive in again, soon

Reply on news.ycombinator.com