decide what to do with funcs that return a Kind when there isn't a good answer

[mvdan]

Take Unions, for instance:

https://github.com/ipld/go-ipld-prime/blob/75dcac7542945f0b3a5b86d625f989974cfa031c/schema/kind.go#L101-L102

"Any" has a similar problem; it "acts like" anything, so we can't return a single kind. And its representation behavior is simiarly unknown. See https://github.com/ipld/go-ipld-prime/pull/324#discussion_r780788448.

Options:

1. Keep what we have now; use Kind_Invalid or "close enough" kinds like Kind_Map. Unfortunate because it's rather misleading.
2. Introduce a Kind_Unknown, meaning "depends on what is stored in it".
3. Make these funcs return (Kind, bool), so that a false return is akin to the "unknown; depends" above.

I think 2, as suggested by @rvagg, makes sense. It's also easier to roll out, as 3 is a breaking change.

cc @warpfork

[warpfork]

Not to take the fire away, but real quick: the "Union typekind acts like Map" one is actually clear and true. I was about to remove that particular comment :)

The other cases around https://github.com/ipld/go-ipld-prime/pull/324#discussion_r780788448 remain.

[warpfork]

+1 to probably favoring Option 2. (Possibly calling it Kind_Contextual?)

I might also offer an Option 4: that we introduce another enum for this concept of "kinds that a typekind can be expected to act as", which is a superset of the kinds enum by this one member.

However, that Option 4 is not generally the golang way of doing things, and would offer precious little concrete advantages, considering that golang doesn't actually have enums in any sense that buys useful compiler guarantees anyway. We'd have another type in the docs, and some of these functions would return this type, so it may have documentational value... but I don't know if that's enough to be worth it.

[mvdan]

I think a separate enum-like type would be good if we were especially worried about users using Kind_Unknown where they shouldn't. But I don't think we really need to worry about that; as long as we write defensive code that errors or panics when it encounters an unexpected kind, and as long as our users write decent tests, then those mistakes should be caught quickly.

I don't have a strong opinion on "unknown" vs "contextual".