Unicode arrows ⇒→←


Hi all,

I wanted to better understand the current position of @heather.miller and the Scala Style Guide team about Unicode arrows, meaning:

  • instead of =>
  • instead of ->
  • instead of <-

As you know the Scala compiler accepts the above Unicode arrows, treating them in the same exact way of their standard two-ascii-chars version.

In particular my question if it is acceptable to use them publicly in mainstream Scala projects.
Of course I am totally in favour, they seem to me to increase the readability of the code.

The only reference I found about this topic is https://issues.scala-lang.org/browse/SI-988. But is 10 years old, and by now the Unicode support is if possible even larger.

If you think this is something that can be promoted, one possibility I have in mind is also to write a scalafmt optional rewrite rule.

I look forward to your comments.




I recommend against them for three reasons. First, they’re hard to type on most keyboards. Second, since you can’t get away from => etc. (because of the first reason), you have to keep in mind that there are always two possibilities for arrows, which an unnecessary complication when, for instance, searching for something. Third, in many fonts they’re smaller and harder to see, and they’re usually really important so shouldn’t be hard to see.

There are fonts with ligatures that make => look like and so on. If it’s just the appearance, maybe you could use one of those.


I am jealous of projects which format arrows to the fancy style I’m unable to type at the keyboard.

Ichoran makes a great point that I’d be unable to search for it in vi.

People usually say that it’s a rendering problem. But I like the idea that the tooling stack could uniformly understand (or conflate) plain ascii and unicode arrows.

I really dislike the eyeglasses I’ve lived with for a couple of years. I’ve been meaning to get regular reading glasses, but who has time for another unsatisfying trip to the optometrist? So Ichoran makes another great point that readability matters. I’m going to investigate code readers; I know there was an effort underway to make Scala readable. Will the tooling say, “arrow” or “arrow fancy”? spoken the way Jim Carrey’s Mask says “smokin’”.


Another irritant is that there are 102 rightward arrows in Unicode and many look alike at normal screen resolutions. In any case nobody uses them and they should probably go away in Scala 3, now that ligature fonts like Fira Code are available and supported by all the reasonable editors.


Thank you for the replies so far.

I agree with @Ichoran that these symbols are very important in the code, and that is why I would like them to be distinguishable and recognizable. To me this is moving towards a more precise and “scientific” notation, exactly like 2² is clearer than 2^2. Preventing combinations like => and >= to signify completely different things. Embracing Unicode, where it makes sense, should not be seen as fancy and futile innovation. And yes there are many fonts and font sizes, suitable for all tastes of arrows and eyesights.

The main point is again from @Ichoran on practicality when actually coding. This is where a Unicode Arrows scalafmt rewrite rule can come into play. Type as you like and let scalafmt take care of the conversion.



I think FiraCode is a very valid and viable alternative, but it does not move the issue forward for the Scala language as a whole, this is why I wanted to understand the position of the Scala Style Guide team.



I started using Java I think around twelve years ago, and as far as I remember I have never used the support for Unicode.

I suppose if you live in a non-English-speaking place and sit in front of a non-English keyboard and write some code you will never share internationally, probably Unicode support makes your life easier. Or maybe to embed some text that is in another language as English as String literals (although I’d much rather have an easy way to put String literals in separate files). But apart from that, I don’t see the benefit of Unicode support at all.

I’d also rather not have ligatures. I just want to see what I type and everything else is at best distracting. It’s also easier to distinguish == and === in non-ligated form (the last one is often used, for example, by scalatest).

Best, Oliver


Having a single glyph doesn’t make things any more precise or scientific than two glyphs (or three, or four, or a word, or whatever). If an individual glyph is hard to type, it’s entirely sensible to use more, easier-to-type glyphs.

If glyphs were really the way to go, we would switch, when possible, to single-glyph symbols instead of method names. For instance, a.map(f) might become a 變 f.

I don’t have any more trouble distinguishing => from <= than I do distinguishing the words “ob” and “do”. If you have trouble distinguishing and/or recognizing => as opposed to <=, use a font with ligatures. That’s what ligatures are for! Traditionally, it was for getting pretty-looking ff and fi and such, but it’s a general-purpose tool that solves the problem you’ve identified, and people have used it to solve this exact problem.


@Ichoran I appreciated the logic of your first reply, but I don’t find anything really helpful here. If glyphs where the way to go people would have emoji on their websites :wink: And I mentioned distinguishing => from >=, so the example comes as “ob” and “bo”, sorry for the confusion.


  • ⇒ → ← are currently supported by Scala
  • the meaning of these symbols is quite relevant and their usage in the two-chars version widespread
  • at least one person, myself, like them for aesthetic and practical reasons, finding the code more readable (“scientific”-like, please note the scare quotes)


  1. If I use them in a public project, am I breaking the house rules? Am I impolite?
  2. Are there plans to increase, maintain, decrease their support in Scala? (if not the latter, something useful could be done)


My experience is that the only truly egregious error in decorum is to omit the space between if and left paren, and in similar constructs, as though the boolean were an argument to if.

I think it’s important to respect local conventions, even while despising them. I understood that the tide had turned against unicode arrow and that future scala will be more opinionated, but I think the time to have had the courage of your convictions was when if then was on the table.

For every language change predicated on a scalafix to make it painless, one can contend that scalafix supports diversity of expression, just as you propose. It would also be a noble effort for a project to supply a scalafix that exports to a foreign convention.

Unfortunately, the reliance on tooling and a general laissez-faire attitude have resulted in uncounted Scaladoc comments with misaligned stars. Although I have a strong opinion in this matter, a consequence of holding the right one, I secretly hope they do away with the evil inheritance of the double star, and instead use the unicode pointing finger hand to introduce a documentation comment. The doc tool would naturally also support the complementary right hand pointing left, for scripts written and presumably read in that direction.


Hi @heather.miller , would you agree that this aspect should be covered on https://docs.scala-lang.org/style/?