[ImPlot support] Ability to provide list of types to use in place of templated parameters

[Ristovski]

It seems like the biggest problem with supporting ImPlot is the fact that it doesn't provide explicitly typed functions, but rather relies on C++ templated parameters, i.e.:

// The templated functions are explicitly instantiated in implot_items.cpp.
// They are not intended to be used generically with custom types. You will get
// a linker error if you try! All functions support the following scalar types:
//
// float, double, ImS8, ImU8, ImS16, ImU16, ImS32, ImU32, ImS64, ImU64

...

#define IMPLOT_TMP template <typename T> IMPLOT_API
...
IMPLOT_TMP void PlotLine(const char* label_id, const T* values, int count, double xscale=1, double xstart=0, ImPlotLineFlags flags=0, int offset=0, int stride=sizeof(T));

sadly with dear_bindings as of now, this generates C bindings which have the const T* values templated parameter in their signature, which fails to compile.

@ZimM-LostPolygon Since you showed interest to get ImPlot working, do you have a plan on tackling this?

cimplot seems to do this by generating a function binding for each explicit type:

https://github.com/cimgui/cimplot/blob/439f705b1cfae0e9fbe42c13ab5b45becc47d404/generator/generator.lua#L188

and frankly this seems like the easiest solution. Perhaps this can be implemented under modifiers akin to mod_flatten_templates? Ideas?

[ZimM-LostPolygon]

Generating a function binding for each explicit type is the only thing you can do with C ABI... That was my plan as well.

My concern is more, do we just hard-code the list of types, or do we try to parse it from IMPLOT_NUMERIC_TYPES, which can be potentially be user-defined?
https://github.com/epezent/implot/blob/f156599faefe316f7dd20fe6c783bf87c8bb6fd9/implot_items.cpp#L94

[Ristovski]

Whoops, I seem to have totally missed IMPLOT_NUMERIC_TYPES!

But your idea is good, parsing the types from it would be neat since then we can support user-defined IMPLOT_CUSTOM_NUMERIC_TYPES as well.

[ShironekoBen]

Yes... it gets a little complicated with a user-defined type that a definition isn't available for, but a little light parsing and possibly typedef resolution feels like it would be a good way to get a list to work from.