Unable to reflect inferred type

[mindplay-dk]

I don't know if you currently want feedback, since you're working on major changes? let me know if this is wanted or not? 🙂

This issue is best explained by example:

class UserRepo {
  getUsers() {
    return [{ name: "Bob", age: "42" }];
  }
}

function run<T>(fn: () => T): T {
  const type = getType<T>();

  console.log(type.id);

  return fn();
}

run(() => new UserRepo()); // 👎 ::invalid::Invalid

run<UserRepo>(() => new UserRepo()); // 👍 @try-rttist/dist/index::UserRepo

The two run calls should return the same type - as you can see here, it's being inferred:

With an explicit type argument, it works, but I'm assuming this should work with inference as well?

Here's a repro for this issue:

https://github.com/mindplay-dk/try-rttist/tree/inference-repro

[Hookyns]

Any feedback is great!

This is definitely an issue.

New reworked solution with separated processes (I call it "typegen", it'll be package @rttist/typegen with "typegen" bin cmd) is based on current version, so any issue in current alpha version will be in the typegen too.

[Hookyns]

With the new transformer, this will be hard to implement. I want to create some simple infer system written in Rust, but it's not gonna be in the near future.

Recently I found this repo: https://github.com/kermanx/simple_ts/tree/main
It is OXC based infer analyzer. We can fork it and integrate into the new OXC based transformer.

[Hookyns]

I've been thinking more about this, and without full type checking, there are 3 distinct problems:

Deciding Whether to Generate a Callsite

If the caller doesn't specify generic arguments, it's unclear whether the transformer should:

• Generate a callsite (i.e. pass generic type information to the callee), or
• Do nothing at all.

This ambiguity makes it hard to decide when transformation is necessary.

Possible solutions:

• Generate callsites for all function calls in the application
  Pros: Ensures all generics are handled.
  Cons: Slower transformation time (compilation) and increased runtime overhead (albeit minimal, but it could matter in performance-sensitive code).

• Implement simple pre-transformation type system
  This system would scan all generic functions and methods in the project, index them, and provide this metadata during the transformation of each file. The transformer would then use this information to resolve which generic function is being called and what type info to inject.
  Cons: Adds build-time complexity and hard to implement.

• Introduce placeholder syntax (like _)
  As proposed in [Make generic types comparable #10], we could use _ (in that issue I mention __) as an explicit signal that generic arguments should be inferred and a callsite should be generated.

  Pros: Simple and straightforward.
  Cons: _ would likely have to be defined as type _ = any, which disables type safety.

  For example:

    foo<_>(value);
  
    function foo<T>(a: T extends "foo" ? Foo : Bar) {}

  Using _ here essentially opts out of type checking for T.

  This solution works well for many use-cases, but the best long-term solution would be to wait for official support for partial type argument inference.

Identifying Generic Parameter Values Without Type Knowledge

Even if we decide to generate a callsite, determining the values of the generic parameters can be tricky if the caller doesn't know them.
For instance, the caller might only be able to say:

The first argument has type #String. The second arguments has type #Number.

But consider this example:

foo("test", 1);

function foo<TFirst, TSecond>(
  param1: TSecond,
  param2: TSecond extends number ? never : TFirst
) {}

First parameter is of type TSecond which is second generic parameter, not first. How should we pair it?
And second parameter is even bigger problem. TFirst is somewhere in the type query.

How should be the callsite handled in this case?
Take this function for example:

function run<T>(fn: () => T): T

Currently, callsites are transformed like:

callsiteCall(callee, context, [/* type argument IDs */]);

So a usage like run<UserRepo>(() => new UserRepo()) becomes:

callsiteCall(run, void 0, ["@try-rttist/dist/index::UserRepo"]);

But if we're inferring the generic using _, the callsiteCall signature would need to change to:

function callsiteCall(
  callee: Function,
  context: any,
  typeArguments: TypeIdentifier[],
  inferredArguments: TypeIdentifier[] // <-- new
)

And run<_>(() => new UserRepo()) would result in:

callsiteCall(run, void 0, [], ["@try-rttist/dist/index::dynamictype1234"]);

On the callee side, we'd retrieve the callsite and see that T is unknown — but that the type of fn is the dynamic type @try-rttist/dist/index::dynamictype1234. The runtime system would then have to backtrack through the FunctionType metadata to determine what T should resolve to.

I can image implementing this in the transformer, based on the type annotation expression, use-case by use-case.

If parameter type annotation is complex, try to match its expression with some of supported use-cases.
Example:

fn get_type_parameter_getter_from_argument_type(param: Param, param_index: usize) -> Expression {
    match param.typeAnnotation {
        TsTypeAnnotation::TsFunctionType(function_type) {
            // ... todo find where the TsType referring to generic parameter is, then if it is return type for example:
            // return AST expression equal to `retrieveArgumentType(param_index).getSignatures()[0].returnType`
        }
        // other cases...
    }
}

Inference Support

This ties into point 2 and is what I was referring to in my earlier comment.

Typegen should handle expressions like () => new UserRepo() and store them in metadata as ad-hoc or inline types. These can then be referenced and passed to the callee instead of explicitly written type arguments.

Another thing is this kind of inference:

const val = x ? new Foo() : new Bar();

run(val);
// or
run(() => val);

The simple_ts project could be integrated to support this kind of basic inference. It won’t handle every edge case, but for quite a lot of real-world use cases, this level of inference would be "good enough."

@mindplay-dk or anybody else, what do you think about it?

[Hookyns]

Another solution may be custom Type Checker, just a simple one.

Before transformation, before whole "compilation" process, I can traverse all the files, including .d.ts files from included dependencies, and create kind of map - mapping TypeIdentifier (those @package/file:type identifiers` to some information we need to solve callsites etc.

It is not difficult to do this, but it will require dual parsing and two traverses of all all the files, it means performance will lower to 50 %. I think it still be much faster than anything with TypeScript (<7). This would be nice to implement with native TS 7 but the API should be available in more than 6 months.