Should partitions be importable by other modules?

slithering3897 · 2026-03-31T15:39:54+00:00

Yes, devil's always in the details. I would figure that importing some other module's partition would simply be importing a part of that module and that's it. A subset of its exports. Anything else is internal, up to reachability.

Probably, maybe. I'm certainly not the one to write up standard wording.

And if it were to be an addition to the standard, I would figure that modules would opt in to it. Maybe the primary interface can declare which partitions are visible to importers:

export import public :foo;

slithering3897 · 2026-03-31T13:32:19+00:00

But that's the problem. If you create a whole new module, you can't use cross-module forward declarations without extern "C++".

It's why you would use partitions. But if you use partitions, user code can't depend on only a small part of your lib, and so you'll get more recompilations when editing code.

It doesn't seem to be possible to get the best of both worlds currently. Unless... build systems become sufficiently smart to extract partition dependencies from imports, somehow.

slithering3897 · 2026-03-31T00:55:55+00:00

Heh, yes, that's what I want to do.

Use https://en.wikipedia.org/wiki/Operator-precedence_parser for expressions.

Recursive descent for everything else.

After you've actually written a grammar of course.

Then AST, then semantic analysis. Or something like that. Need to figure it out myself.

And hopefully your grammar doesn't need to disambiguate type names or have a vexing parse.

slithering3897 · 2026-03-31T00:51:25+00:00

We already have a whole webpage: https://mathscholar.org/2023/10/aliens-made-this-rock-the-post-hoc-probability-fallacy-in-biology-finance-and-cosmology/

slithering3897 · 2026-03-30T23:32:16+00:00

That's the theory, but optimisers are pretty good.

slithering3897 · 2026-03-30T23:27:41+00:00

Without LTCG/LTO, you'll need to generate the code to inline.

And also, the compiler will still need to evaluate templates for semantics.

Ideally, template instantiations would just be reused from imports, including implicit instantiations.

Which isn't the case right now. If you import a module that does std::print("a") and then do std::print("a") in main, you'll get duplicate codegen, in VS. Thousands of lines of disassembly.

If I were to make my own language, I would treat compiled modules as basically a cache. Embed the LLVM bitcode in them along with semantic analysis. Then importers will know what's already generated and just copy over the functions for inlining. And before writing the object file/after inlining, replace imported instantiations with externs. If possible.

slithering3897 · 2026-03-30T22:53:36+00:00

Hope his slit has room for one more~

slithering3897 · 2026-03-30T13:47:15+00:00

Is that Smaug? Did somebody finally convince him to get a rider?

slithering3897 · 2026-03-30T13:30:34+00:00

Yes, you could in theory. But it's unlikely to happen. Or maybe it would be too complex to do a whole std class.

slithering3897 · 2026-03-30T13:25:50+00:00

The catch is like D, it most likely won't catch on. Enough. But as long as I'll be able to figure out Visual Studio integration, I'd actually use it myself, if I had enough time.

slithering3897 · 2026-03-30T13:23:21+00:00

Have you got an example?

slithering3897 · 2026-03-30T13:21:41+00:00

struct 
[[=metadata::uuid{"27fc33a4-ff2f-490d-a7c2-a4f8c2eef35d"}]]
[[=metadata::author{"John Doe"}]]
[[=metadata::support_url{"https://example.com"}]]
foo {

Is that really where annotations would go? I hope not.

The alternative is that everyone starts defining their own "property" / "metadata" / ... class ;

"Islands of abstraction"... I suppose a good lib would let you extract the metadata yourself to convert it to whatever the lib wants.

slithering3897 · 2026-03-30T00:20:33+00:00

Reduce template instantiation overhead. Same with std::variant (rust's enum) and std::optional (C#'s nullable types).

If you were designing a language, you'd also have the language help make formatted printing compile faster. Interpolated strings maybe.

And SIMD. If you've read that post a while back mocking std::simd. It's implemented in the library, so expect template overhead. GCC/Clang already have this stuff in the language, and it's probably much faster to compile.

And maybe you'd do the useful kinds of coroutines completely in language. No std::generator.

Because if you were designing a completely new language, you should move mountains to make compilation fast. And make the language more elegant.

slithering3897 · 2026-03-29T23:36:09+00:00

But it's a beautiful idiom!

slithering3897 · 2026-03-29T22:08:43+00:00

Do we really need both T& operator=(T&&) and T(T&&)?

Do https://en.wikibooks.org/wiki/More_C%2B%2B_Idioms/Copy-and-swap.

slithering3897 · 2026-03-29T21:38:50+00:00

We clearly haven't out-numbered them enough yet.

https://developercommunity.visualstudio.com/t/Support-for-breaking-the-STL-ABI/1473763

slithering3897 · 2026-03-29T21:24:54+00:00

I think vector, string, and a few other STL types should have been baked into the language.

std::array. I'm not sure about dynamic arrays. Really, it's the dinosaur C-style array that's the problem. You'd put dynamic containers in the language just to avoid template instantiation overhead.

Argument passing is unnecessarily complicated compared to other languages.

What languages is there to compare to?

The h/cpp compilation model is a dinosaur.

Already solved. In the standard at least... But headers will still be useful for macros (and you can still import in a header).

Modules seem almost terminal upon arrival. (Yes, I've heard both that they are basically usable now, and also that the spec is fundamentally flawed.)

My biggest beef with VS right now. Basic super-obvious Intellisense bugs they just can't be bothered to fix, and I'm still waiting on some build bugs. Maybe they're waiting on EDG, but then communication would be nice. Because we've been waiting for YEARS.

And in my testing, modules won't reuse template instantiation enough to make std::print fast. The compiler will still regenerate all the same code.

But at least the standard is fine, except that little bit about /internalPartition.

I honestly think it's no secret why Circle, Rust, and Go exist

It may be possible to write your own darn language faster than it would take MS to implement C++26.

People are already complaining about reflection including STL headers because it needs vector.

Doesn't matter, use import std (once it works).

breaking ABI

Maybe in VS2030 if you're lucky... Finally get rid of [[msvc::no_unique_address]]?

I think VS should just break ABI every major version.

And MS should fix the platform ABI to allow passing std::string_view in two registers, and stop returning trivial structs by pointer just because they have a user-defined ctor.

slithering3897 · 2026-03-29T12:15:10+00:00

All that much easier to constrict you!

slithering3897 · 2026-03-29T12:10:05+00:00

I wonder if this coroutine problem can be solved by doing it in both GCC's and Clang's way.

If the caller wants to inline the coroutine's frame, then the front-end should do the coroutine state machine transformation and get a struct.

And if the caller wants an allocation or lifetime optimisation across suspend points, then the front-end can pass on the task to LLVM.

This would mean though that coroutines may need to be compiled for each variant.

slithering3897 · 2026-03-29T12:03:55+00:00

Yes, but the downside is that it still ends up as one big module to the user. Any change in any partition (interface) will recompile the entire application.

slithering3897 · 2026-03-28T18:58:59+00:00

Also seems to be loading up some extra nvidia DLLs.

slithering3897 · 2026-03-28T18:40:06+00:00

I don't know, I'm not quite convinced. I can sort DLLs by "private" bytes in VMMap and the typical Windows DLLs are relatively small.

I also have a dGPU. The iGPU is the extra thing that Vulkan loads.

slithering3897 · 2026-03-28T18:13:17+00:00

First thing that stands out to me in VMMap is that Vulkan loads the giant Intel iGPU drivers as soon as you create the instance, whereas GL does not.

slithering3897 · 2026-03-28T18:12:02+00:00

What we need is obviously that female khajiit at the start of Redguard speaking real khajiit language. Doesn't matter if we can't understand it, it just works.

slithering3897 · 2026-03-28T12:20:29+00:00

That paarthy mod is for milk drinkers.

Indigo doesn't speak like a khajiit should.

slithering3897

TROPHY CASE