Generalize external types

[knuton]

Spaghetti currently supports external interfaces, but not external structs which seems like an arbitrary limitation.

It would be sensible to introduce the notion of an arbitrary external type:

extern ns.foo.Bar

We could allow to use external types in arbitrary positions, e.g.

interface BarSub extends ns.foo.Bar {}

however this might mean that if ns.foo.Bar is not of an appropriate kind in the host environment, the error is only detected after the headers have already been generated and the host language compiler runs.

So we could allow to specify the "kind" of an external type when declaring it, but extend this to struct:

extern interface ns.foo.IBar
extern struct ns.foo.SBar

We could still allow for types of unspecified kinds as

extern type ns.foo.TBar

which can only appear in member or function declarations.

[lptr]

I agree that extern interface without an extern struct is not good. But instead of adding the latter, I would go for dropping the qualification of extern altogether (possibly allowing for interface for backwards compatibility with a deprecation warning, but ignoring it nevertheless).

The way I think about it, Spaghetti's goal is to make your compiler more clever, so that it can catch errors before the code ever gets executed. Adding a struct or interface qualification to extern doesn't work towards this goal: if the compiler would allow the extension, why would Spaghetti stop you from doing what you want? And if the compiler doesn't accept the resulting generated code, well, the problem is caught by the compiler, so all is well anyway.

[knuton]

And if the compiler doesn't accept the resulting generated code, well, the problem is caught by the compiler, so all is well anyway.

I'd like to challenge this argument on the grounds of cross-language semantics: There shouldn't be surprises about what happens after Spaghetti compiles the headers and the host languages' compiler_s_ take over. If we suspend judgement about which constructs can extend which other constructs, we increase the chances of ending up with a situation where the headers compile in one host language, but not in another.

Is this not a problem?

[lptr]

I think extern is about marking an entity as not being under Spaghetti's influence. Hence the user is on their own with externs. What would you have Spaghetti do instead? I think some concrete examples would be handy here.

Without examples that prove that adding qualifications to extern, I think we should aim for flexibility, i.e. Spaghetti should not constrain the user in something it doesn't understand.

[knuton]

I guess my concern is that Spaghetti does have some semantics independent of the host languages, it has to understand some things (though this is not explicitly defined now). Spaghetti structs are not Spaghetti interfaces. But in some host languages, both are compiled to that language's "interface" construct.

	interface	struct
Haxe	interface	typedef
TypeScript	interface	interface
Kotlin	interface	interface

If we drop the differentiation at the extern level, programmers may come to rely on the implementation detail that both structs and interfaces are represented as interfaces in one language, then run into unexpected problems in languages where the two are represented differently elsewhere.

Example:

1. Dev A adds an extern type T to declare the return type of a method
2. Dev B in the same module extends an struct from T, this compiles because the underlying type in the host language happens to allow it in combination with its representation of structs
3. When using the same module with another language, the combination is illegal and compilation fails unexpectedly

By using qualifications to extern, Spaghetti can enforce more (if not complete) consistency across languages and thus decrease the chance of headers compiling in one but not another host language. Unqualified externs should still be allowed, but those types can not be extended, only accepted in argument positions and return types.

Programmers would be able/forced to make more of their intent explicit and get more help from the compiler.