Request: different instances of core-js/library should return the same Symbol.iterator

[Macil]

Background: Babel with the "runtime" transformation essentially translates code using Symbol to use require('core-js/library').Symbol. The "runtime" transformation seems to be necessary for well-behaved libraries that need ES6 polyfills without polluting the global context or requiring the application to do so.

A problem occurs when a babel-transpiled library (using the runtime transformation) wants to be able to interoperate with iterable objects created by other babel-transpiled code (and they don't happen to share the same instance of babel-runtime/core-js, which will be the case if they weren't compiled with the same exact version of babel, or if neither babel-transpiled-library depends directly on the other and npm prune was not used). If a global Symbol.iterator is present, then it works fine because core-js returns that global one if it's present. If a global Symbol.iterator is not available (node 0.10.x, or most non-Chrome and non-Firefox browsers), then the library and the application / other libraries will each have different values for Symbol.iterator, and won't ever recognize objects created by each other as iterable.

Here's an example of an issue with a babel-transpiled library: webmodules/node-iterator#1 . I brainstormed a few ways that the library itself could work around the issue, but they didn't strike me as very good. I think core-js or babel would be better positioned to solve this, though I'm not sure on the specifics, and I'm interested in any discussions.

Possible core-js solutions:

• require('core-js/library').Symbol.iterator could always evaluate to a specific hard-coded string. Relevant: Facebook's regenerator library falls back to using the string "@@iterator" for Symbol.iterator if Symbol isn't available.
• The first instance of core-js/library creates a random string to use as Symbol.iterator, stashes it in some globally-visible location (like a non-enumerable property of window/global), and future instances of core-js/library use that value.

[zloirock]

In own methods, core-js has fallback to "@@iterator", if you need create common iterator in library version, instead core.Symbol.iterator you can use this string.

I'll think about it.

[zloirock]

I thought about both solutions before.

• First creates more problems than it solves. JSON {"@@iterator": 42} can break code - Array.from, Dict, Object.getOwnProperty(Names|Symbols)... For this reason I wanna remove fallback to "@@iterator" from internal methods.
• More preferably the second variant, I wanted to add it before, but decided not to do it after The core-js/library module is setting global.core #18 . But, I think, I will do it - add global variable like __core-js_symbols__ with well-known symbols, AllSymbol and SymbolRegistry stores.

Ideas?

[Macil]

I hadn't thought of the symbol registry. That puts me heavily in favor of the second solution since even more than Symbol.iterator benefits.

No big downsides of the global way jump out at me besides a little bit of pollution, but on the plus side that pollution only happens for environments that don't yet have Symbol present natively (and don't have a global polyfill loaded).

[zloirock]

Full rejection of the "@@iterator" string can create problems with regenerator.

cc @benjamn @sebmck thoughts? Maybe make @@iterator in regenerator modifiable?