Should `constructor` and `prototype` be special-cased to always be strings?

[LeaVerou]

Split out of #75 (comment)

Reasons to special-case:

• You pretty much never want symbols there, so requires constructor implements protocol { ... } is a footgun.
• Without the special-casing requires constructor creates a protocol.constructor symbol, but in Protocol instances, protocol.constructor should point to Protocol. And while protocol.prototype would be blank, it does break assumptions about what obj.prototype is, and prevents us from using protocol.prototype for inheritance.
• Defining class statics is a common enough use case that it originally had dedicated syntax

Reasons to not special-case:

• Slight increase in mental model / handling complexity

I’m personally moderately strongly in favor of special-casing, but @michaelficarra and @ljharb had reservations. Could you elaborate what these were? (feel free to edit this comment so we have all the pros and cons in one place)

[LeaVerou]

From today’s breakout with @michaelficarra: @michaelficarra is unconvinced about whether the value this adds is worth the mental model complexity. One thing we are aligned on is that constructor and prototype should NOT create symbols because indeed this is a bug farm.

So the options are:

1. constructor and prototype are implicitly strings (my preference — intent is clear so there is no reason for an error condition)
2. They are an error (that way we can at least do 1 in the future)

I would argue that the additional mental model complexity is already there, since we're gonna have an exception either way. So I don't see any benefit to doing 2, personally.

[ljharb]

I prefer 1; they already have special behavior in class bodies and almost every library, it won’t be confusing.