String.prototype.padLeft / String.prototype.padRight

[Norbert Lindenberg]

The TC39 meeting in September discussed a proposal to add padLeft and padRight methods to String; the relevant section of the meeting notes [1] is attached below. A revised proposal is on the agenda for the upcoming November meeting [2].

Comments on this proposal:

1) The proposal notes that “string padding functions exist in a majority of websites and frameworks”. Unfortunately, it doesn’t provide information on the use cases for which applications need these functions. Without use cases, it’s hard to tell whether the proposed methods are adequate, overengineered, underpowered, or misdirected.

2) The discussion about the unit used for the length arguments can’t be resolved without knowledge of the use cases to be addressed. I can imagine use cases where code units are appropriate, others where code points are appropriate, yet others where tailored grapheme clusters [3] are required, and finally some where padding is required based on the width when rendered with a given font. I don’t know which ones are prevalent in applications in general, and the proposal doesn’t say. If the ones involving font rendering are the most common ones, I’d suggest that the API is not appropriate for ECMAScript because ECMAScript doesn’t deal with fonts.

3) The names of the methods are inappropriate. “Left” and “right” are visual directions, and whether the first or the last characters in a string (or some characters in the middle) are displayed to the left or the right, is decided by the Unicode Bidi Algorithm. Padding, as proposed here, is an operation on logical strings, so “padStart” and “padEnd” should be used. This aligns with the existing startsWith and endsWidth method. Aligning with trimRight/trimLeft is misguided, because these names are equally wrong (they had to be kept because browsers already shipped with these names) [4].

4) Step 10 in the proposed method specifications (“Let truncatedStringFiller be a new String value consisting of repeated concatenations of filler truncated to length fillLen.”) is broken for the case where fillString contains one or more supplementary characters. I can’t imagine a use case where an unpaired surrogate in the result string is the right outcome.

Regards,
Norbert

[1] https://mail.mozilla.org/pipermail/es-discuss/2015-October/044354.html
[2] https://github.com/tc39/proposal-string-pad-left-right
[3] http://www.unicode.org/reports/tr29/
[4] https://mail.mozilla.org/pipermail/es-discuss/2015-July/thread.html#43667


On Oct 6, 2015, at 11:49 , Rick Waldron <waldron.rick at gmail.com> wrote:

> ## 5.10 Proposal: String#padLeft / String#padRight 
> 
> (Jordan Harband, Rick Waldron)
> 
> https://github.com/ljharb/proposal-string-pad-left-right
> 
> JHD: (run through history of proposal)
> 
> - min length vs. max length semantics? min length semantics with repeat. max length is the desired functionality. 
> 
> AWB: re: min length and max length, concerning unicode characters, code points. 
> 
> JHD: Issues will exist in _any_ string apis. This API doesn't use code points, can be changed to do so. Length property wouldn't be useful. If filler is a surrogate pair, I can use a multiple of it's length... 
> 
> - Max length is in code points?
> 
> DH: re: terminal output, do control characters count against length?
> 
> JHD: Yes, always. 
> 
> Discussion, re: code points vs. latin centric characters 
> 
> BT: This API is no different than existing APIs
> 
> JHD: really want to solve this? Change everything to use graphemes
> 
> AWB: interpret "length" as simply: "number of occurrences of your fill character"
> 
> DD: assumes the rest of your string is Emoji. Never going to get the width correct.
> 
> AWB: if it doesn't do the right thing in the real world, why?
> 
> BT: Trying to do things beyond the simplest use case is just untenable.
> 
> RW: Intl could adopt responsibility for a non-latin character set handling?
> 
> BT: Agree. 
> 
> Derailed into discussion about what gets to go in the standard library and what gets defined in a standard module.
> 
> DH: (To Rick) Not cool to attack other specs when inclusion of proposal is questioned.
> 
> Note: I made a comment that if two string methods are "too much", then we should revisit SIMD for the same concerns.
> 
> Back to padLeft, padRight...
> 
> DH: Clearly important if implementers are agreeing to implement before other features. 
> 
> Discussion re: stage 1 or 2?
> 
> AWB: For stage 2, controversy resolved. 
> 
> JHD: Then stage 1. 
> 
> #### Conclusion/Resolution
> 
> - Stage 1
> - Reviewers to be assigned.