out_str support for C native types

[mario-tux]

Hi,
I'm using your M*LIB with great satisfaction! I like its style but also the "array[1] trick" that I love and already use in GMP/MPIR, PBC and in all my own code. I've started to use it in one new big project and I'm wondering about some details.

I'm trying to get an out_str support for any new defined type: mainly for debugging purpose. It looks that string_t got the out_str method in the STRING_OPLIST. I was, wrongly, assuming that all the native numeric type (int, float, ...) in C got such support but I can't get any composition including such types printable in automatic way: I have to define a specific out_str method. Is it normal?

Other marginal questions/curiosities:

• can I ask the meaning of the _DEF macros with the suffix 2 (like TUPLE_DEF2)? I saw in the commitments log a renaming of a macro from _DEF2 to _DEF: is it something like "it is a draft"?!
• I there something like "API breakage vs versioning" in your mind? Can I develop a software saying that it requires m-lib with version greater-equal to something and expect that the code will not break?
• If your last answer is like "something could change on new releases", I wondering if you could include in the main header m-core.h a define with the numeric version; in this way I can make a check in meson to verify such version to a specific one.

PS: maybe this should go into an email but I was not able to find you email address.

Thanks.

[P-p-H-d]

Hi,
I am glad that you are satisfied with M*LIB!

1. There is no way in C99 to print a default type in an automatic way.
   However it is now possible in C11 with _Generic... and it was nearly already implemented in M*LIB with M_FPRINT_ARG!
   I have finished implementing it properly, and it is available: now you should get automatic output with the native numeric types with '-std=c11' by using the default oplist.

2. I am not really sure myself :)
   The current meaning is that _DEF2 macro applies with more than one couple (type,oplist) whereas _DEF applies only for one couple (type,oplist). This can be seen with the different B+TREE macros.
   DICT_SET_DEF2 has been renamed into DICT_SET_DEF in order to be homogeneous with this rule.
   However I am open to better rules.

3. I really like API stability and try to avoid breakage as much as possible... However I also would like to have a clean, sane & uniform API. And the current state is unfortunately not good enough: not bad, but it needs a little bit more polishing. That's why I try to put as much as possible API breakage now, as soon as possible, in the first alpha releases of the library when few people use it.

So to answer your questions, future API breakages can occur. However :

• the API breakage details shall be justified and fully described in the doc/API.txt file including information on how to migrate.
• implementing a compatibility layer to limit possible breakage is possible (for example keeping the old name for a full version before being deleted),
• some part of the API are more stable than other.

Since I see that the library is being used, I'll try to limit the breakage if possible :)

4. version numbers are definitely missing in m-core.h
   I have added them.

[mario-tux]

Thank you for the kind reply and the quick fixes!