Directly import String.prototype.toLowerCase/toUpperCase

[eqrion]

It looks like a number of things were removed because they could be directly imported.

toLowerCase/toUpperCase are not possible to optimize to much more than just a function call, and can be directly imported.

You should be able to import toLowerCase/toUpperCase using:

Function.prototype.call.bind(String.prototype.toLowerCase)

This is optimized in V8 and SpiderMonkey AFAIK.

[sjrd]

Maybe I'm alone with this opinion, but I still have a hard time agreeing that the Function.p.call.bind trick qualifies as "directly imported". It's a fairly involved trick. The things that were removed because they could be directly imported can really be directly imported: Math.cos is the function that you import, for example. It has the same identity.

The original JS string builtins contains several methods for which we could have used the bind trick instead: charCodeAt, substring, concat. They received builtins anyway. What is different about them?

• Is it that we had not yet found the trick, and we would not make the same decision today?
• Are they more optimizable than a function call? (charCodeAt probably, but concat or substring maybe not)
• Are they just considered much more common?

[eqrion]

Is it that we had not yet found the trick, and we would not make the same decision today?
Are they more optimizable than a function call? (charCodeAt probably, but concat or substring maybe not)
Are they just considered much more common?

Good qustion, I think it's a combination of all three. The 'trick' wasn't well known or optimized (TBH, we optimize it only a little bit). All of these functions also have special inline paths and optimizations in the SM JIT, and are pretty common in code.

One other odd part about the concat and substring builtins are that they intentionally reduce the domain of their inputs to simplify the implementation. The actual JS concat methods will perform value to string coercions that are unnecessary with the builtin. Substring also has odd behavior around OOBs indices or swapped indices that the builtin (IIRC) avoids. I have mixed feelings about this, but the intention was to make it a very simple primitive that was easy to inline.

It's a gray area, but I don't think that toLowerCase/toUpperCase will receive any more optimizations from being a builtin vs being imported.

I'm sympathetic to the func bind 'trick' being ugly. I honestly think the CG should find a standard way to have wasm import something with a receiver, but no one has had time to do that. The js-type-reflection proposal introduces a WebAssembly.Function interface which could have a flag for this, but that proposal is in limbo now.

[sjrd]

Thanks for the details.

I'm a bit sad to see them go. Though looking at the current state of the proposal, they are the odd ones left there. Perhaps it's better to remove them.

I'm sympathetic to the func bind 'trick' being ugly. I honestly think the CG should find a standard way to have wasm import something with a receiver, but no one has had time to do that. The js-type-reflection proposal introduces a WebAssembly.Function interface which could have a flag for this, but that proposal is in limbo now.

A generic, standard way to import functions with a receiver would be very nice. If we had such a feature, I guess we wouldn't even have the current discussion. Hopefully this makes a comeback at some point.