I understand there could be different ways to translate letters into numbers, and also there are many different typing systems. Regarding of why we would like to use code units, instead of grapheme clusters, I think it is a simple default option for this syntax and would not exclude the possibility for it to be extended by extra code. The dot with the operator would save code like the following, by default, regardless of encoding:
function offsetString(str, offset) {
let result = '';
for (let i = 0; i < str.length; i++) {
let char = str.charAt(i);
if (char >= 'a' && char <= 'z') {
result += String.fromCharCode(char.charCodeAt(0) + offset);
} else if (char >= 'A' && char <= 'Z') {
result += String.fromCharCode(char.charCodeAt(0) + offset);
} else {
result += char;
}
}
return result;
}
If instead of my example of adding a string to a number directly,
'a' .+ 1
We could use a function that returns a number, then does the math according to the preferred encoding.
let myString = "Hello World";
function customOffset( s, n){
// do some math about required encoding
n = n + 255;
return n;
}
console.log(myString .+ customOffset(myString, 1));
Even when there is the need to use grapheme clusters , the new syntax with the operator could still save the need for the offsetString function, just like in the above code.
Built-in language functionality like charCodeAt, fromCharcode(), and also codePointAt() could coexist with the above solution.