Negative arguments for C++ non-type template parameters interact badly with left-arrow ligatures

[chiphogg]

For example,

auto foo = Constant<-1>;

The <- renders as an arrow. It just looks wrong.

Never mind how realistic this example may or may not be. 🙂 I actually encounter non-type template parameters routinely in my codebase.

Perhaps the ligature could be disabled if the <- is followed by digits and/or a ., with a , or > afterwards? I don't have any idea how ligature disabling works, but I've noticed that it happens if, e.g., I keep typing multiple ###... or ///....

[philippnurullin]

Hi @chiphogg . I'm looking for solution right now. How many digits you think can be in <-1>?
Please provide more examples.
We may find a solutions but OpenType is pretty "forward" language.

[chiphogg]

In my use cases, it's only ever been single-digit numbers. I'm sure that would cover the majority of use cases, although I see no reason it couldn't be more.

(If it helps motivate my request, the context is in strongly-typed unit systems, and the non-type template parameters refer to the exponents for fundamental dimensioned quantities. So, for example, a strongly-typed "acceleration" type would have something like time_dimension<-2> as a template parameter.)

[philippnurullin]

Looks like a made exclusion in the wrong ligature. ))
Sorry, will correct it few days.

[philippnurullin]

Should be correct now.
Feel free to reopen otherwise.

[kawazoe]

I came to report a similar issue in TypeScript generic types. While it isn't specifically about the <- ligature, it is still related to generic types/template syntax.

There are ligatures for >>> which can trigger in types like Promise<Map<string, Foo<number>>>. It only impact spacing, so maybe the font could include some special kerning rules for cases like >>>(, >>>[, >>>; and >>>\n which I believe are the most common odd looking ones; they all end up with a large amount of white-space on the left. The double arrow version (>>) seems to behave better in that regard.

However, I also tried the repro for this report and it doesn't appear to be fixed in the version shipped with WebStorm 2022.2.1. Could it be a regression?