Expose some internal types, so custom operators can be built

[Groxx]

The request in a nutshell: can enough internal details be exposed to allow building custom operators externally? Ideally in a stable way.

I very much realize this is not a simple request, but someone has to make it :) Maybe it can serve as a placeholder for planning / discussion. Some context / broader reasoning is below.

---

TestDeep looks super interesting! From a quick glance it looks like there are a lot of good, flexible, well-thought-out features, especially around good error messages (that's so rare, thank you!).

While there are quite a few built-in operators, there are always some edge cases that benefit from custom ones. The JSON operators serve as a nice example of this: it's just a string, but there's a lot of structure that can imply much-better error reporting and a simpler API, so it has a custom operator to improve things.
Unfortunately, though td/types.go exposes the TestDeep interface, the base type is not exposed, and location.GetLocationer deals with the (afaict) internal-only Location type, so custom operators cannot be built outside this library. There may be other causes as well, this one was just one I saw while reading.

This is... probably a very reasonable choice for API stability, but somewhat crippling for less-common needs. I assume you don't want to collect every ill-advised and poorly-implemented operator that every user/company/etc dreams up, so being able to build things from the outside would be great. It could also enable "enriching" libraries that enhance TestDeep.

Is there a way this can be done?

[maxatome]

Hi, thanks for your interest.

The td.TestDeep interface is, at the time of writing, intentionally unimplementable outside go-testdeep repository to allow it to change in the future if needed. Note that it does not change often, but it has 2 months ago, for last updates of JSON operators for example. See it as a security measure to evolve easily, and to not be an end in itself. If we think the interface is stable, I am not against making it implementable.

If you need to add special use cases, or simili-operators, you can abuse of Smuggle operator (note you can use a function with an interface{} parameter) or combine several operators in one function returning the final one (named combo-operator) like it is explained in the FAQ. I work on making the operator Location settable for combo-operators makers, stay tuned.

By the way, if you think a use case is so common that it deserves its own operator, and no existing operator can compete, we can discuss about its addition in td package.

Do you have a use case in mind that Smuggle operator cannot address?