Per May 2016 TC39 consensus, String#{padStart,padEnd} is now stage 4!
#581
Conversation
| 1. Let _O_ be ? RequireObjectCoercible(*this* value). | ||
| 1. Let _S_ be ? ToString(_O_). | ||
| 1. Let _intMaxLength_ be ? ToLength(_maxLength_). | ||
| 1. Let _stringLength_ be the number of elements in S. |
| 1. Let _intMaxLength_ be ? ToLength(_maxLength_). | ||
| 1. Let _stringLength_ be the number of elements in S. | ||
| 1. If _intMaxLength_ is not greater than _stringLength_, return _S_. | ||
| 1. If _fillString_ is *undefined*, let _filler_ be a string consisting solely of the code unit U+0020 (SPACE). |
There was a problem hiding this comment.
The draft consistently uses U+ notation with code point or character, not code unit. Also, String?
There was a problem hiding this comment.
I discussed this with @bterlson in stage 3, and this was the preferred mechanism.
The capitalization seems to have been made consistent since I initially wrote the text - will update!
There was a problem hiding this comment.
oh actually, it's lowercased in a number of places - I think we should make them all consistent in a separate commit/PR.
|
To be clear, I don't think putting code unit and U+ together makes sense. They are a little different. The standard seems to typically use "character"... |
|
@annevk hmm - it seems that all the previous examples have been converted to use "0x" notation - grep the spec for "string consisting". I'll happily convert this from "U+0020" to "0x0020" though. |
|
You still have "a string" and "a new String value". |
|
Both capitalizations are identically equivalent and appear numerous times throughout the spec. |
|
Wouldn't you want to use a single style inside one algorithm though? Anyway, up to you all... |
|
Fair enough :-) updated. |
| <emu-note>The first argument _maxLength_ will be clamped such that it can be no smaller than the length of the *this* value.</emu-note> | ||
| <emu-note>The optional second argument _fillString_ defaults to *" "* (a String consisting of 0x0020 SPACE).</emu-note> | ||
| </emu-clause> | ||
|
|
||
| <!-- es6num="21.1.4" --> | ||
| <emu-clause id="sec-properties-of-string-instances"> |
There was a problem hiding this comment.
The logical placement of the new clauses seems wrong. In order to respect both section hierarchy and alphabetical order:
- they should be placed between subsections
String.prototype.normalizeandString.prototype.repeat, inside (and not after) section "Properties of the String Prototype Object"; String.prototype.padEndshould be placed beforeString.prototype.padStart.
There was a problem hiding this comment.
I intended to place them at the end of the section "Properties of the String Prototype Object" - I didn't realize they were supposed to be alphabetized. I'll fix both.
(tc39/proposal-string-pad-start-end#23)