Syntactic sugar to offset

Being an untyped language, ES allows us to do great things like:

    >'a' + 1
    >'a1'

What if we want to just offset our string/char by simply adding an symbol along with the operand.

    >'a' .+ 1
    >'b'

If the dot is before the plus sign, it should offset what's in the left.
If the dot is after the plus sign, it should offset what is in the right.

    >'a' +. 1
    > 2

Bonus

    >'aaaaaa' .+ 1
    >'bbbbbb'

    >'aaAAbbBB' .+ 1
    >'bbBBccCC'

Why would we want to operate on code units, instead of code points, or grapheme clusters?

Great question,

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.