A concept-centered standard library for C++20, enabling safer and more reliable products and a more modern feel for C++ code.; Also home of Subdoc the code-documentation generator.
I think it would be probably nice to be able to use Subspace without fmtlib as a dependency. Though then it's not possible to use them with streams either so maybe that's kinda a terrible situation.
Make a subspace/fmt/ directory.
Move the fmt-to-iostream support code there, along with tests.
Add subspace/fmt/foo.h header for each type, put the template specialization in there.
The headers in there should only need forward declarations of Subspace types, as all code lives inside template instantiations which are only used from code that has the Subspace type visible?
Now there's two paths:
Users get fmt and streams support out of the box:
Add #include "subspace/fmt/mytype.h from subspace/real/mytype.h. It can be behind a CMAKE-controlled define still.
Users need to include a header themselves to get fmt support:
Add subspace/fmt/subspace.h that includes all the fmt/foo.h headers.
Users now have to include something from subspace/fmt/ to use fmtlib or streams.
Then it would be straightforward to lift the subspace/fmt/ directory up to fmtlib as well, in which case #include "fmt/subspace.h" could become possible just like #include "fmt/std.h", inverting the relationship between the libraries.
To be honest, the first path seems better, with implicit support for fmtlib, at least at the moment.
Once named modules are normal and useful, and you can just import fmt-sus; (from fmt) or import sus-fmt; (from subspace), then maybe things change. Right now it's important to limit include parsing, so everything gets split apart, so needing a bunch of includes for string support is kinda bad.
I think it would be probably nice to be able to use Subspace without fmtlib as a dependency. Though then it's not possible to use them with streams either so maybe that's kinda a terrible situation.
subspace/fmt/directory.subspace/fmt/foo.hheader for each type, put the template specialization in there.Now there's two paths:
#include "subspace/fmt/mytype.hfromsubspace/real/mytype.h. It can be behind a CMAKE-controlled define still.subspace/fmt/subspace.hthat includes all thefmt/foo.hheaders.subspace/fmt/directory up to fmtlib as well, in which case#include "fmt/subspace.h"could become possible just like#include "fmt/std.h", inverting the relationship between the libraries.To be honest, the first path seems better, with implicit support for fmtlib, at least at the moment.
Once named modules are normal and useful, and you can just
import fmt-sus;(from fmt) orimport sus-fmt;(from subspace), then maybe things change. Right now it's important to limit include parsing, so everything gets split apart, so needing a bunch of includes for string support is kinda bad.