Contradiction in 20.3.4.41 Date.prototype.toString note 2

[bathos]

The second note for Date.prototype.toString states:

The toString function is intentionally generic; it does not require that its this value be a Date object. Therefore, it can be transferred to other kinds of objects for use as a method.

However, the algorithm begins with this step:

Let tv be ? thisTimeValue(this value).

The thisTimeValue operation is not generic; it throws a TypeError if the receiver does not have a [[DateValue]] slot.

I believe this note is likely a mistake, unless I am misunderstanding what “generic” signifies here.

[allenwb]

Note that in ES2015 it was generic because it used NaN as the TimeValue the [[DateValue]] field was not present.

Hopefully, there was a reason that was changed and why the generic method note is out of date.

[claudepache]

Note that in ES2015 it was generic because it used NaN as the TimeValue the [[DateValue]] field was not present.

Hopefully, there was a reason that was changed and why the generic method note is out of date.

See #850.

Here is the broader context for those that weren’t born during the heroic times of es6 standardisation: In the beginning, Date.prototype was a Date object (i.e., an object with a [[DateValue]] internal slot). At some point in time, it was made into an ordinary object. Then, Date.prototype.toString() was made generic, so that stringification of Date.prototype (included implicit one as in alert(Date.prototype)) wouldn’t accidentally throw. Finally, it was made non-generic nonetheless for reasons mentioned in PR #850.

[allenwb]

As speculated in #850 the ES6 specification for Date.prototype.toString was indeed based upon the long and nuanced discussion at https://mail.mozilla.org/pipermail/es-discuss/2014-June/037630.html

Unfortunately, there is no indication in the May 2017 meeting notes that any of the points from that thread were presented or discussed when asking the committee to change the ES6 design.