Type check and promotion for js interop

[jodinathan]

A feature of the Typings package is that it makes predicate (type guards) in TS (function isFoo(arg) : arg is Foo;) a method that returns the object promoted instead of a bool.
While creating it I thought that we may have what is needed to make a type check system for js interop:

• For js classes we can do instanceof to check
• For js interfaces we can execute the type guards when available

We could have an argument in the @JS or @staticInterop annotation that would map the types to the checks.
Something like

@JS()
class Foo {
}

@JS(
types: {
  Foo: 'isFoo' // interface type guard
}, 
classCheck: 'isOf' // in the case of real class, we can make generic checks with instanceof
)
class Bar {
  bool isFoo();
}

Then when a type check is used (bar is Foo) the dart analyzer and compiler would follow some logic like in:

// bar is Foo

if (statically bar is DartType) { 
  // continue to the original dart type check system
} else if (statically bar is JsInterop) {
  if (statically bar.isJsClassInstance) {
   // check the type by calling bar.isOf(Foo)
  } else if (statically bar.hasFooCheck) {
   // check the type by calling bar.isFoo()
  } else {
    throw 'There is no type check for Bar to Foo';
  }
}

[eernstg]

@jodinathan, it isn't obvious to me how to interpret this issue as a Dart language proposal. Perhaps it fits better into a repository which is concerned with the design of the upcoming version of JS interop?

@srujzs, do you have an idea about the best placement for issues like this?

[jodinathan]

@eernstg yeah, agreed.
I didn't know where to put it and didn't want to increase the SDK issue list.

[srujzs]

I think if the goal is just to get nice is checks, we could perhaps use a kernel transform on is checks to lower to instanceof when the right-hand side is a JS interop interface. It's a bit surprising, so I think an opt-in mechanism (like annotation metadata in the above example) is useful. Maybe we want something similar for as?

We've thought about similar things with our interop design, because unlike dart:html classes, is checks don't do much with interop. It is desirable to use is instead of instanceof, or at least warn users that is doesn't work the way they want it too.

My favorite idea for this is a new language feature that allows users to add an operator is on top of a inline class. When a type check is done, it'll first call that method if it exists, and otherwise calls the underlying is that we use today. That's probably overkill for what we want here, but at least it's unsurprising and idiomatic. :)

This can go in the SDK under the tags area-web and area-jsinterop if a language feature is out of scope in the mediumish-term.

[eernstg]

Thanks, @srujzs! I think it makes a lot of sense to have an overall approach where JS interop (and interop in general) uses Dart types to express a level of static guarantees which is actually backed up by the underlying semantics, and then provide access to features like a JavaScript instanceof as a separate mechanism, or at least only support it as the semantics of Dart constructs like is or as if there is an explicit opt-in, and only on certain (interop) types.

In any case, and similarly to FFI, this discussion is specific to the behavior of some Dart programs on some platforms, which means that it won't be considered part of Dart-the-language, and it won't be part of the language specification.

This supports the placement of this kind of discussion in the SDK repo, with said labels. I'll transfer the issue and add the labels.

[sigmundch]

I think what remains open from the language perspective is:

• Would the language accept/consider overloading is for inline-classes?
• If so, what are the semantics?
• If so, would we do static type promotion?

For example, imagine:

@JS('JSX')
inline class X {
  JSObject rep;

  static operator is(o) => js_interop.instanceof(o, 'JSX');
}
...

foo(o) {
  if (o is X) { // this generates code like: o is JSObject && X.is(o)
    // do we promote o to X here?
  }
}

Today the alternative is to write this:

@JS('JSX')
inline class X {
  JSObject rep;

  static operator is(o) => o is JSObject && js_interop.instanceof(o, 'JSX');
}
...

foo(o) {
  if (X.is(o)) {
    var ox = X(o);
    // use ox, instead of o
  }
}

Given that there is a simple alternative, we are not yet convinced that we want this feature. It looks convenient, but we worry that there are hidden costs with it which may be higher than the benefits.

[eernstg]

If we want that, I think we should introduce a language repo issue for a user-defined is operator (in general, or as a special feature for inline classes).

However, we've discussed this kind of feature several times during the evolution of inline classes, and it's a path with many obstacles. For example, we may be able to run specialized code for e is I in the case where I statically resolves to an inline type, but how do we handle e is Y where Y is a type variable with bound Object?, or e is List<I>, etc?

On the other hand, we may already have a partial solution (I renamed X to C because I tend to assume that X is the name of a type variable):

@JS('JSC')
inline class C implements JSObject {
  final JSObject rep;
  bool get isValid => js_interop.instanceof(this, 'JSC');
}
...

void foo(JSObject o) {
  if (o is C && o.isValid) {
    ... // `o` is promoted to `C` here.
  }
}

The clause implements JSObject uses an extension of inline classes that the language team has not yet accepted, but it seems likely to me that we will have it (and I'd support that!). It allows an inline class to specify that it is a subtype of a type which is not an inline type, as long as it is a supertype of the representation type. So we're basically "revealing" the representation type (or parts of it).

So what I've done in the example above is

• Change C such that it is a subtype of JSObject. This means that regular promotion can take place from JSObject to C (but the type test o is C is a no-op at run time, it's statically guaranteed to yield true).
• Add an explicit validationo.isValid. This implies that it is genuinely OK to treat o as a C.

This means that promotion to an inline type can be used by a developer to express the intent to access a given object using that inline type, and the validation code can be executed in order to ensure that this kind of access is valid.

Consider the case where the inline type occurs as a subterm of another type:

// `inline class C` declared as before.

void baz(List<JSObject> os) {
  if (os is List<C>) { // Promote the list as a whole.
    for (var o in os) {
      if (!o.isValid) continue; // Validate each element in the list.
      ... // `o` is promoted to `C` here.
    }
  }
}

This illustrates that it is straightforward, in some cases, to handle the higher-order usage where the inline type occurs as part of some other type (promotion "just works"), but it is obviously going to be difficult to use a lint or warning to ensure that any kind of validation is actually performed whenever we have this kind of indirect promotions to an inline type.

The case where an inline type is the value of a type argument is basically only relevant as seen from the call site:

// `inline class C` declared as before.

void foo(JSObject o) {
  var c = bar<C>(o);
  ... // `c` is a `C` typed way to access `o`.
}

Y bar<Y extends JSObject>(JSObject o) {
  if (o is Y) return o; // But we have no way to know that it should be validated!
  throw "Ignore other situations";
}

At run time, in the body of bar, the value of Y is JSObject. We have no way to know that it was provided as C at the call site, and hence we can't even discover that we might need to call something like C(o).isValid in the body of bar, even in the case where we have been thinking about that situation during the development of bar.

During the evolution of the inline class feature we discussed several designs where it could be supported by the runtime that type tests like o is Y would run a user-defined validation routine. However, those proposals never got sufficient support from the language team. One particular worry was that it might be a non-zero cost for some dynamic type tests/checks where the target type was not an inline type, or even if it was an inline type that did not have any non-trivial validation (that is, it might not be pay-as-you-go, and that would be unacceptable).

[jodinathan]

I am not sure if adding an is operator overload is the best option because people could abuse it.

The great thing about Dart is that it isn't magical as other languages.
(I don't even like overriding == and hashCode)

However, JS interop is magical by nature, so we could do anything here to make it easier for clients.