review

[Michael Ficarra]

This proposal is ready for review. https://tc39.github.io/Function-prototype-toString-revision

Designated Reviewers

• @wycats
• @erights
• @waldemarhorwat (with caveat that we agree on not including surrounding whitespace)

Editor

• @bterlson

Reminder of Requirements

• for functions defined using ECMAScript code, toString must return source text slice from beginning of first token to end of last token matched by the appropriate grammar production
• for built-in function objects and bound function exotic objects, toString must not return anything other than NativeFunction
• for callable objects which were not defined using ECMAScript code, toString must return NativeFunction
• for functions created dynamically (through the Function and GeneratorFunction constructors), toString must synthesise a source text
• for all other objects, toString must throw a TypeError exception

[Michael Ficarra]

Update: Tests are now available at tc39/test262#553

[Mark S. Miller]

This looks good to me.

Good job!

[Michael Ficarra]

Thanks for taking a look, Mark.

[Brian Terlson]

LGTM!

Couple possible improvements to spec text for your consideration:

1. CreateDynamicFunction step 31 can start with: Let sourceText be the String value whose elements are the concatenation of the code units of keyword, " anonymous(", .... I think this will read easier.
2. Function.prototype.toString step 2 has a lot of non-observable logic to explain a simple concept. In these cases I like something simpler like replacing the entire step with:
3. Return func.[[sourceText]] with all occurrences of the code unit sequence 0x000D (CARRIAGE RETURN) 0x000A (LINE FEED) replaced with the single code unit 0x000A (LINE FEED) and all occurrences of the code unit 0x000D (CARRIAGE RETURN) removed.

[Brian Terlson]

Actually I'm confused at what the current spec text says. It seems to be saying to preserve the \r on the first pass (removing the \n) and removes the \r on the second pass, and so has the effect of removing lone \r and \r\n pairs. Is this the intent?

[Michael Ficarra]

@bterlson

CreateDynamicFunction step 31 can start with ...

I prefer the current version because it distinguishes sequences of code units from individual code units.

step 2 has a lot of non-observable logic to explain a simple concept

I totally agree, and I like that wording, but I avoided it in favour of the more explicit form because of how things like String.prototype.replace are worded. I will change it.

Actually I'm confused at what the current spec text says

Sorry, if that's what it says, it was unintentional. I meant what you've suggested.

[Brian Terlson]

I prefer the current version because it distinguishes sequences of code units from individual code units.

Can you explain why this distinction is important? My pedantic self likes it but I'm not sure there's valuable information in the more verbose language for implementers.

[Michael Ficarra]

@bterlson I just think it makes it more clear what is intended.

Also, I've pushed 7bac51e, simplifying step 2 of Function.prototype.toString as you suggested.

[Brian Terlson]

Ok, I still don't see how it's possible to be confused with the simpler wording of step 31 but I'm willing to defer to your judgement here :)

I like 7bac51e. But now I'm wondering, why is the first step necessary? I'm back to thinking maybe I don't understand the intent of this. Can we just say "remove every carriage return"?

[Brian Terlson]

Never mind, I see the intent now is to replace \r\n with \n and \r with \n. Carry on (and fix the wording I proposed).

[Michael Ficarra]

For future archaeologists: 96e73b6.

[Michael Ficarra]

Closing. Proposal has been advanced to stage 3.