[aleksiy123]

I pretty much always prefer using an options struct as soon as there is more than one optional argument.

Comes out cleaner because overriding a default argument doesn’t force you to also do all the positional arguments in front of it.

Designated initializers make it look really nice imo. I feel like the brackets are no big deal.

Python has sort of the opposite when you need to use *kwargs.

[DarkUranium]

I use this all the time in C (specifically, C99 or later). I first saw it used in anger in `sokol_gfx`, and loved it. `FLECS` does something similar.

C makes it much better than C++ in that the designated initializes can be set in any order --- so I don't need to remember the often-arbitrary order of struct fields for the options struct.

I find it weird that C++ took this great C feature and kneecapped it ...

[DarkUranium]

Addendum: I've been wanting to make my own shading language (for a number of reasons), and this feature is one I'd definitely include.

Think (for example) using a pluggable PBR module in this way, where you give it a config/options struct instead of a weird combination of `#if`, runtime arguments, and predefined uniforms and/or function names.

[delta_p_delta_x]

> I pretty much always prefer using an options struct

This is essentially what Vulkan does; there's a CreateInfo struct for every object creation or command function. And even then they managed to sort of mess it up, because they also have functions and objects suffixed with a '2', and the pNext extension mechanism.