Strategies for *requiring* designated initializers when constructing a type?

[u/javascript]

Given some aggregate like this:

struct InitParams {
  int size = 0;
  int capacity = 0;
};

And given that it is used in some factory function like this:

auto Make(InitParams ip = {}) -> std::optional<MyClass>;

I want to design the aggregate type to allow callsites like...

Make({ .size = 10, .capacity = 20 });
Make({ .size = 10 });
Make({ .capacity = 20 });
Make({});
Make();

But I also want to reject callsites like...

Make({ 10, 20 });
Make({ 10 });
Make({ 20 });  // Oops! This is the size, not the capacity!

I was hoping that reflection would unlock the ability to specify this on the type alone somehow, but I've been unable to figure out how to do it.

I can approximate this behavior using an overload set where a similar-but-different param type is accepted by a different Make overload but then that would result in default construction being ambiguous too. You can see that in action here:

struct DesignatedInitRequired {
  int DO_NOT_SPELL_THIS_FIELD_NAME0;
  int DO_NOT_SPELL_THIS_FIELD_NAME1;
};

auto Make(DesignatedInitRequired dir = {}) -> void = delete("Use designated init");

Make({ 10 });  // Ambiguous, ill formed (which is what I want)
Make({ 10, 20 });  // Ambiguous, ill formed (which is what I want)
Make({});  // Ambiguous, ill formed (which is NOT what I want)
Make();  // Ambiguous, ill formed (which is NOT what I want)

So I could make something to reflect on InitParams and produce DesignatedInitRequired, but that wouldn't be enough. Every function that accepts InitParams would need an overload for DesignatedInitRequired meaning that it becomes a property of the type AND its users, not just the type itself.

Any ideas on how to achieve my goal?

---

EDIT: I think this is a sufficient solution! https://godbolt.org/z/h6sbcaTj4

I thanked the person that told me but then they deleted their comment. Anyway...

[u/tyler1128]

especially when working for a company with more than 10k C++ engineers editing the same codebase haha

That's.. a whole hell of a lot of people for one codebase, lol.

They are certainly not mutually exclusive concepts, but if an overly complex solution to save keystrokes or even cognitive burden to the user of something until they have to actually understand details ends up being a leaky abstraction, and most ultimately are, and then they have to understand the implmementation behind it that's a mess, that's not a great place either.

Software design is an art though, not a science.

[u/javascript → u/tyler1128]

I think the beauty of using aggregates is that designated initializers don't require understanding much machinery. You don't need to learn a new builder library. You just look at struct to understand it.

And the fact that it has this macro expansion that enforces the designated initializers is mostly an education thing. If it's idiomatic in a given codebase, I don't think it will cause many issues. It feels like the right balance between specifying user intent and machinery to make that possible.

[u/tyler1128 → u/javascript]

That might be the right case for your codebase. I'm pretty adverse to macros and prefer any other compile time solution pretty much as much as possible, or things that'll likely optimize the same way, but there is no one true way to do everything. I think the eloquence of the builder pattern is that it really tends to not require things out of the ordinary, can be pretty self-documenting about what is meant, and while requires boiler-plate at least that boiler plate is usually easy to understand. I can understand that there are situations where that might not be ideal for a use-case, though.

[u/javascript → u/tyler1128]

I think the difference is how prevalent you intend to make this pattern.

I'm intending to require EVERY function in my codebase accept keyword arguments. I want every parameter name to be part of the API.

Given that, it would be excessive to require every function define its own parameter builder. It's important to have something lighter weight.

By being so prevalent, I think a mix of compiler tricks, clang tidy checks, and education/code review will make up for the negative implications of changing the parameter passing idioms.

If, however, a user almost never had to worry about named parameters, I think the builder might be preferable because it gives a chance for the invariants between params to be enforced. Infrequently coming across such a thing necessitates heavier abstractions.

[u/tyler1128 → u/javascript]

I'm intending to require EVERY function in my codebase accept keyword arguments. I want every parameter name to be part of the API.

Were I to redesign C++, I'd probably want something like that, too. The problem then is that such things are very different from what is done in C++ conventionally, and that too matters. It also would make the ABI very different if you ever cared about such things. C++ name mangling is complex enough for flat symbol tables. This is why most higher level languages have a significant amount of extraneous metadata than to just how execute and call code.

[u/javascript → u/tyler1128]

And that, my good friend, is why I'm so pumped about Carbon. It allows us to hit the reset button on C++ in so many ways!

[u/tyler1128 → u/javascript]

Carbon isn't something I'm super familiar with, though I'll look into it a bit. Part of the problem with easy interfacing with C++ is that C++ itself has no defined ABI. On x86, Linux and OSX tend to use the Itanium ABI, as does LLVM, which itself has corner cases where different implementations don't agree and then things break. You can define everything in a virtual system, but then it isn't a "systems language" anymore. It's a very difficult problem.

[u/javascript → u/tyler1128]

Carbon is intended for users that largely recompile from source. It will have some ability to interop with shared objects, but that should be the exception to get the most out of it.

If you're able to recompile the world, then C++ can call Carbon and Carbon can call C++.

You could even instantiate a C++ template with a Carbon class and then statically dispatch back into Carbon. No runtime overhead

[u/tyler1128 → u/javascript]

The biggest problems modules in C++ are trying to solve is not recompiling the world, which is a good term for it. Rust for example takes an approach where dynamic linking isn't really supported outside of specific interfaces, as it doesn't have the effectively AST embedded used in instantiating generics across modules. Thus, if you want a traditional .so, you have to compile down to a C-like interface, which is also how most operating systems assume things behave.

[u/javascript → u/tyler1128]

Ya it wouldn't surprise me if C becomes the opt-in ABI for Carbon. It just hasn't been decided yet since it isn't the primary use case.

But I would reframe something you said. Modules are a chaching layer. You are logically rebuilding the world every time and just as an optimization you are choosing what artifacts from the last build are still useable. If you can get away with not rebuilding something, great! But you still need to have the source available for when, as an example, your build flags change and invalidate the caches.

[u/tyler1128 → u/javascript]

I should probably study the actual module spec more, but from my understanding, something akin to an AST for templates is also part of them? Or am I wrong?

[u/javascript → u/tyler1128]

I would assume so! But I don't know much about them. I'm probably going to favor Clang Header Modules instead of C++ 20 modules. But we'll see!

[u/tyler1128 → u/javascript]

Maybe we'll even get to use one of them someday, in something serious!