This would be a good enhancement. A relatively simple solution would be exposing TypeConverter publicly so that it could be used as a base class and registered as well:

from robot.api import TypeConverter

@TypeConverter.register
class MyConverter(TypeConverter):
    ...

Would that work for you @JFoederer?

Exposing TypeConverter via robot.api would be trivial, but there would also be some other work needed:

• Go though TypeConverter to make sure its public API makes sense. We cannot easily change it anymore if it's exposed publicly.
• Add documentation to all methods and attributes in the public API.
• Add documentation, with examples, to the User Guide.
• Tests. This could probably tested pretty thoroughly with unit tests using the already exposed `TypeInfo´ (Add public argument conversion API for libraries and other tools #4942), but some acceptance tests would be needed as well.

Nothing above is too complicated, but there's quite a bit to do. I won't personally have time for that withing RF 7.0 timeframe, but I'd be happy to help and review PRs if you @JFoederer or someone else want to take a look at this.

Yes, that would work, because that is the exact method I am now using as a work around. My proposal is to first bring my own library up-to-date with the RF7 changes, secretly still using the unexposed interface. If that works fine we at least have a working example and it gives us some time to think a bit broader and investigate possible alternatives, without the time pressure. It would be great to formalize this towards RF8 though.

Sounds good. I don't think this is too big a task and it shouldn't have any backwards compatibility concerns, so it could be done already in RF 7.1. We basically just need to make sure the TypeConverter API is as lean as possible and we don't accidentally expose internal logic publicly.

There most likely isn't time to get this done in RF 7.0. That said, if you have ideas how to enhance the TypeConver now so that it would work better as an official public API, let me know. If we can make the API stable already now, then it's easy for users to support also RF 7.0 by just importing TypeConverter from a different place.

A few considerations regarding libdoc around this topic:

• When registering a converter for a new type using @TypeConverter.register, libdoc generation currently fails. It expects the type to be present in STANDARD_TYPE_DOCS from robot.libdocpkg.standardtypes. It should be possible to add a custom types list that is extended automatically by the register decorator, making use of the type's docstring.
• When using generic types it is useful to have access to type_name from robot.utils for user reporting.
• Generic types are decoupled from their nested types. So, when you have MyType[int] and MyType[float], then usages link to all keywords using MyType, regardless of the nested type. This is probably ok for some situations, but not correct for others.

Potential issue with libdoc. If the non-technical type name contains spaces, then the html render fails to display the type's docs in the type info dialog.

Quick comments to the topics above:

• Global converters obviously should be able to conveniently provide their own documentation. I guess they could have a doc attribute and we could use __doc__ as a fallback.
• There's currently a hard error if a type isn't in STANDARD_TYPE_DOCS to make sure we don't forget adding those docs. That's a good thing in general, because I would have otherwise forgotten that several times (last time with the recently added Literal). I can see that it's rather annoying in your use case, and we can think about making the API nicer even before officially supporting global converters. Possibly we could move the standard docs to TypeConverter docstrings already now.
• robot.utils is considered stable (we make changes and remove outdated utils, but always with a deprecation period), which means that type_name can be used just fine.
• Can you elaborate where MyType part of MyType[int] and MyType[float] linking to same documentation would be an issue? Linking types to type docs is far from trivial, and I would only touch it if there are really good reasons to do that. It anyway shouldn't be part of global converter support.
• Type names with spaces not being shown correctly in HTML is a bug that should be fixed. Please submit an issue.

Issue submitted as requested for the html rendering.