Just an observation now that I've compiled with 2....

# javascript

[Edoardo Luppi]

Just an observation now that I've compiled with 2.2.20.

The new String.substring approach is better because it directly calls JS' substring, however it now produces:

substring(response, startIndex, endIndex);

Where substring is:

function substring(_this__u8e3s4, startIndex, endIndex) {
  _init_properties_stringJs_kt__bg7zye();
  // Inline function 'kotlin.js.asDynamic' call
  return _this__u8e3s4.substring(startIndex, endIndex);
}

If instead you bring back inline for those two functions https://github.com/JetBrains/kotlin/blob/400e1ecadbef70744b6ee7eb6234a0a6ea8bbda8/libraries/stdlib/js/src/kotlin/text/stringJs.kt#L274-L276
you won't have to pass by the lazy initialization of the file-level properties. A similar situation is valid for Long too as far as I can see.

Alternatively properties could be marked with EagerInitialization.

[Artem Kobzar]

Sounds doable. Could you please fill out a ticket for this?

[Edoardo Luppi]

Will do. I'll finish diffing the compiled files to see if I can catch other differences

[Edoardo Luppi]

The only two other differences I see are because of the commonization of IrLinkageError, and because (I guess) of the Long/BigInt refactoring. Some of the arithmetic over Long seems to have been moved to extension functions, so there is an additional level of indirection + lazy initialization of boxedLong.kt properties.

For example:

function equalsLong(_this__u8e3s4, other) {
  _init_properties_boxedLong_kt__v24qrw();
  return _this__u8e3s4.h3_1 === other.h3_1 && _this__u8e3s4.g3_1 === other.g3_1;
}

[Edoardo Luppi]

Ahhh. Before Long methods/functions were also calling those top-level functions. So it's actually better now.

[Edoardo Luppi]

https://youtrack.jetbrains.com/issue/KT-80859