Deprecate Symbol.species

[ilias-t]

Given this proposal aims to remove the ability to use Symbol.species to subclass, and since the proposal is now in stage 1, would it make sense to deprecate Symbol.species at least in documentation like MDN to signal this intended behavior and reduce future usage of it?

[mhofman]

I actually just audited our codebase and found one instance where we're testing for the existence of Symbol.species to determine if the environment is ES6 compatible. Admittedly not great, but I'm sure lots of other similar cases exist in the wild.

Also, I believe we don't want to prevent people from building their own species type subclassing.

[syg]

@ilias-t Note that Stage 1 is, IMO, a much weaker signal than deprecation. We're still unsure if the machinery can be removed at all due to web compat. It is jumping the gun to mark it as a legacy or deprecated feature currently.

[ljharb]

@mhofman fwiw in the cases i've seen, "ES6 compatible" can mean a different thing; no engine that has symbols lacks Symbol.iterator, but every other well-known Symbol is "missing despite Symbol support" in at least one version of at least one engine.

[ilias-t]

Even if it’s too early to deprecate, I’d suggest that the main goal here should be to signal a warning to developers that it may be a risk to depend on this moving forward.

[codehag]

@ilias-t if I am not mistaken, the use case you are describing might not be in danger. What is being proposed for removal is how it interacts with subclassing.