Lifting the type restrictions on gobind requires first designing what the interface will look like in Java and Obj-C, and then implementing it in the code generator.
We have some ideas for what we could do with the currently unsupported types, but haven’t put much time into it. There are several things that need to be considered. In particular: these high-level cross-language function calls are always going to be relatively expensive compared to a normal function call, so it’s not just a matter of finding a matching type that will work, but designing one that is useful.
For example, for a function that returns a struct S, the easy thing to do in Java is to return the same type as we would for *S. That is, a Java class with getters and setters. However, that’s not particularly useful. It increases type coverage, but doesn’t offer any more useful features to someone designing a package for gobind.
More useful could be, given:
type S struct {
X int
Y string
}
func F() S { ... }
gobind could generate the Java
class S {
public int X;
public String Y;
public static S F() { ... }
}
This would mean returning S instead of *S copies the fields across the language boundary at each use, which in some cases would be more expensive and in some cases less expensive than the referencing we do for *S. What are the implications of this? Where is some code that could use this well? (This is very similar to how nano protobufs work: https://github.com/google/protobuf/tree/master/javanano, so code that uses it could be used as an example.)
To do this, someone has to take the time to think this through and write it down. Issues like: what is the Java class called? (Does it conflict with the existing *S generated code?) A proposal would almost certainly involve building a prototype first and finding a use for it. I expect it to be quite a lot of work. If you would like to take it on, please go for it.
There are several other type restrictions well worth lifting, that are filled with a lot of corner cases. In particular, named types. It’s entirely possible, it’s just a lot of detail work.
The first step is becoming very familiar with go/types. An intuitive understanding of Go’s type system is not a good place to start with this sort of work because it is easy to miss uncommon details. Reading through the go/types API and its implementation is probably the best way to learn the details.