String.prototype.padLeft / String.prototype.padRight

[ecmascript at lindenbergsoftware.com]

On Nov 16, 2015, at 0:18 , Jordan Harband <ljharb at gmail.com> wrote:

> 1) The primary use cases in my opinion are monospaced command line output, or preformatted text output in a webpage.

These both make assumptions about font rendering: One glyph per Unicode character, each glyph the same width. ECMAScript is used in a wide range of applications where these assumptions do not hold, and baking them into API causes problems. I think API that primarily is intended for, and limited to, these use cases should be part of libraries for these use cases.

> 2) ECMAScript only has two concepts: code units, and code points - it does not handle grapheme clusters, and if it were to add support for this, these proposed methods could be adapted to handle them in the same way as all of the pre-existing string methods. The issue of code units versus code points has been resolved in https://github.com/tc39/proposal-string-pad-left-right/issues/5 to the satisfaction of the designated spec reviewers and the spec editor.

The conclusion on issue 5 apparently is:

1) Some other programming languages provide functions that are partially broken, so ECMAScript can do the same.

2) Supporting a correct solution “would greatly complicate the algorithm”.

In the two years that I attended TC39 meetings (2011-2013), such arguments were rarely made, and I don’t think they ever ended the discussion. Careful analysis of use cases and in particular of edge cases was the norm.

> 3) The naming is set in stone - `reduceRight` sets a clear precedent that "right" is "the length minus one", and has no relationship to the visual direction, and based on `trimLeft` and `trimRight`, which are already implemented in basically all browsers Thus, in ECMAScript, "left" is not considered a visual direction but rather a synonym for "start" and "index 0". The naming is also mentioned here: https://github.com/tc39/proposal-string-pad-left-right#naming

A stage 1 proposal isn’t set in stone. As Claude pointed out, reduceRight is not a good precedent because arrays have no visual order. The content of strings is commonly associated with a visual order, and that visual order is often not the same as the logical order.

> 4) Per your second question and https://github.com/tc39/proposal-string-pad-left-right/issues/5, this is intentionally not a concern of this proposal.

Per 2) above, it is.