Exclude fails when provided generic parameters

[joprice]

Issue created from Glutinum Tool

Glutinum version - 0.11.0-preview

TypeScript

type Omit$1<T, K extends keyof T> = Pick<T, Exclude<keyof T, K>>;

Error

undefined is not iterable (cannot read property Symbol(Symbol.iterator))

TypeError: undefined is not iterable (cannot read property Symbol(Symbol.iterator))
    at sA (https://glutinum.net/assets/index-DpVFw9B_.js:9:7849)
    at X1e (https://glutinum.net/assets/index-DpVFw9B_.js:11:17206)
    at Od (https://glutinum.net/assets/index-DpVFw9B_.js:12:2990)
    at c8t (https://glutinum.net/assets/index-DpVFw9B_.js:30528:20859)
    at f8t (https://glutinum.net/assets/index-DpVFw9B_.js:30528:22474)
    at Glutinum.Converter.Reader.Types.ITypeScriptReader.ReadTypeNodeZ64B23DD2 (https://glutinum.net/assets/index-DpVFw9B_.js:30892:132575)
    at https://glutinum.net/assets/index-DpVFw9B_.js:30518:10324
    at https://glutinum.net/assets/index-DpVFw9B_.js:11:18264
    at zO (https://glutinum.net/assets/index-DpVFw9B_.js:11:16628)
    at m_ (https://glutinum.net/assets/index-DpVFw9B_.js:11:18236)

Problem description

When Exclude is provided a generic parameter, it fails to parse. I'm guessing this is because it is treating the type as something to be expanded in place, but it is as of yet unknown. Perhaps instead when the type alias is generic, it can be registered as a type-level function, generate no code, and then its application be deferred until a call-site.

[MangelMaxime]

When starting to handle TypeScript utility, I saw this problem coming.

By "this problem", I mean people creating their own version of TypeScript utility types. And at the time, I decided that I will not handle it (yet?) and people should not write their own utility and just use the one coming from TypeScript.

However, Glutinum should not crash when seeing code it can't hand so at worth it should default to obj or something similar to #130 if there are generics.

[MangelMaxime]

To complete my message perhaps in the future Glutinum will not have this restriction but I think it would require a deep rework or at least a lot of work to be able to detect custom utility types and resolved then when called.

Right now I try to focus on "more common" cases, and would like to take a first stab at adding React -> Feliz support.

[joprice]

Yea it makes sense. You might end up with a mini compiler embedded in glutinum. I agree Feliz-style React bindings generation would be great, as glutinum doesn't help much there currently and it can be time-consuming and error-prone to write those.

[MangelMaxime]

You might end up with a mini compiler embedded in glutinum

Indeed, I am trying to push it as far as possible because once we go down this path the code will increase in complexity by a lot.

I will already need, to add a mini compiler to check some of the F# generation once I unwrap union types in members.

Also, for TypeScript we have the advantage of being able to ask it to compile/calculate the actual value of a type. The only problem, when doing so is we leave the AST world to go in the Symbol world which is even less documented and have less information available from what I see.

I am using already using the Symbol stuff of TypeScript in some places because I know it is limited in scope at these places.

Regarding Feliz style binding, we need good standard support for them to be possible. But, I think we are closing in now.

I am just not sure yet, if I will make the Feliz adaption using from the GlueAST (TypeScript) or from the F# AST.