Dynamic library loading as part of STL.

[LouChiSoft]

This is probably going to be a bit of an off-topic suggestion. But honestly I don't know where better to suggest it so here goes:

One of the goals of Cpp2 is to simplify the language and the library. One of the things I think could be simplified and added to the STL is runtime loading of dynamic libraries. While not a hugely common practice, it still comes up often enough for me at work and in my own personal projects that a standardised version would make a tangible improvement to my code. I also think that with a bit of creative coding and metaclasses you could get standardised plugin library as well.

Disclaimer: Not a compiler engineer, what I suggest might not be possible as I suggest so I am open to feedback to make the idea better.

Premise:
Instead of using dlopen/LoadLibrary to open a library and then have to use dlsym/GetProcAddress to find functions you should be able to do the following:

// The most basic version to load a library. Notice the lack of file decorations, e.g. .dll/lib prefix
// These are added by the library function
my_lib: std::shared_library = ("lib_to_load"); // (library_name: string, add_decorations: bool = true)

// The same as before but with explicit .dll file extension. The false here tells the STL to not add
// decorations based on platform. Useful for when different platforms might have different base 
// names for the same library. E.g. vulkan-1.dll on Windows and libvulkan.so on Linux. 
my_lib: std::shared_library = ("lib_to_load.dll", false); // (library_name: string, add_decorations: bool)

Then once you have your library loaded you should be able to load functions based on the function name and signature. For example, if your library declared a function called foo that took two ints and return a float it could be done so as follows:

// Load function by template parameters. The first parameter being the type of arguments it takes, and
// the second parameter is the return type
my_func := my_lib.load_function<std::tuple<int, int>, float>("foo");

value: float = my_func(5, 10);

That's the basic premise for the library functions. And to be honest most of that is just standard C++ that doesn't need anything from Cpp2. But I think with Cpp2 and metaclasses you could go further and support plugins. Take the following use case; a user application that supports extending the application via plugins akin to Unreal Engine or Blender. Using metaclasses I think the process of developing a plugin framework could be simplified enough that it could in theory be made part of the standard library. Warning: this is where the suggestion goes from "I'm pretty certain this can be done" to "I'm not experienced enough in compiler development to know if this is possible" so feedback is appreciated

The first step would be to provide the @plugin metaclass as part of the library. The second step would be to define a plugin specification in a library somewhere. E.g.

// application_library.ixx

export application_plugin_spec: @plugin type = {
    start_up: @initializer (context: application_context);
    shut_down: @terminator (context: application_context);
}

Some things of note here, first off @plugin is essentially a fancy version of @interface. It also uses metafunctions instead of metaclasses which I know aren't officially supported, but they have been experimented with by people in the community. This example uses them here to define a function as the initializer AKA automatically called when the plugin is loaded and a terminator AKA automatically called when the plugin is unloaded.

Then with your plugin spec defined a user can link against your library to implement their plugin:

// my_plugin.ixx

import application_plugin_spec;

my_plugin: application_plugin_spec type = {
    start_up: (context: application_context) = {
        context.do_something(/**/);
    }

    shut_down: (context: application_context) = {
        context.undo_something(/**/)
    }
}

Again, similar to the a regular @interface if the user were to link against your application library and try to compile their plugin without implementing either start_up or shut_down they would get a compiler error and message telling them they need to implement it. Or IntelliSense error before that.

Finally the application itself would link to the application library and use the plugin type to load plugins at runtime

import application_plugin_spec;

main: (args) -> in = {
    /*
        some start-up code
    */
     context := get_application_context();

    plugin: std::plugin<application_plugin_spec> = ("path_to_plugin_library", context); // start_up automatically called here
} // shut_down automatically called when plugin goes out of scope

If you've reached this far, I thank you for reading my ramblings and appreciate it. Like I said before, I'm not a compiler/toolchain engineer so I don't know if this is actually feasible. But I personally think it would be a large step up above C++ in it's current state. I do have other ideas for making linking/loading shared libraries in C++ a better experience as a whole but that goes from "kinda off-topic" to "wildly off-topic" for the context of Cpp2 so I shan't share them here.

Thanks for reading