Expose JS function outside of SDK

[ranquild]

What do you think about exposing JS function outside of SDK code? This is very useful optimization, can be used by framework-level code.

JS('var', '#[#]', this, index);

Kotlin does this already https://kotlinlang.org/api/latest/jvm/stdlib/kotlin.js/js.html

[kevmoo]

thoughts @rakudrama @sigmundch ?

[lrhn]

I've definitely wanted that when writing platform-specific code. The affordances of dart:js are not impressive, and I didn't want to depend on package:js for something which was really mainly calling Math.imul.

Typing is an issue. It's a variadic function, which we can't do, so either it needs to be special-cased throughout the toolchain, or it has to just be typed as Function. The latter would prevent tools from helping you with the type of the first two arguments.

The "type string" (first parameter) might not be very user-friendly. It's designed for internal use, and looks quite powerful. Would we want a slightly simpler syntax if we release it for general use? Or maybe make the function generic so you write JS<int>("Math.imul(#, #)", v1, v2) instead of using a string.
There are things you can't write then, but it's quite a lot more readable to general Dart users.

[rakudrama]

JavaScript interop via @JS() annotations is the supported way of interacting with JavaScript.
Lasse, if the code you are writing is part of the platform you can use the @JS annotation from dart:_js_annotations.

#29623 requested making ES6 math functions available. I think we should do that, and include imul (and clz32) so that anyone can write portable code with this function, even if it is strange and redundant on the VM.

@patch
int imul(int a, int b) => (a * b).toSigned(32);

The magical JS pseudo-function is very complicated and fragile. The 'type string' extends to describing all kinds of behaviour that is interesting to the compiler and, if wrong, can break the compiler.
The 'type string' for DDC and dart2js are completely different and incompatible.

JS is already generic, but usually the type parameter is inferred. A Dart type is not sufficient. It is important to know in uses like imul that the fragment never returns null, even in legacy mode. When 'tree-shaking' we need to know if the JavaScript fragment instantiates the type, or just returns an instance created elsewhere. The instantiated types need to be a union as there is no interesting common supertype in many cases, e.g. int and bool, and saying that a fragment of code can instantiate any class is a tree-shaking foot-canon.

[joshualitt]

Closing due to the preference for using js-interop over exposing internal SDK constructs.