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.
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
>= 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).
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
<= 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 And I mentioned distinguishing
>=, 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)
- If I use them in a public project, am I breaking the house rules? Am I impolite?
- Are there plans to increase, maintain, decrease their support in Scala? (if not the latter, something useful could be done)
Hi @heather.miller , would you agree that this aspect should be covered on https://docs.scala-lang.org/style/?
it seems it would be sufficient if your editor supported the desired visualization of regular arrows. This way the code base need not contain any fancy symbol and you still have what you desire, right?
Here’s why you shouldn’t use Unicode operators: https://nrinaudo.github.io/scala-best-practices/tricky_behaviours/unicode_operators.html
They change the meaning of the code because they have different precedence from their ASCII versions.
Pet peeve: all scala programs consist entirely of unicode characters by definition. The first line of the SLS reads
Scala programs are written using the Unicode Basic Multilingual Plane ( BMP ) character set
the arrows are deprecated in Scala 2.13 (https://github.com/scala/scala/pull/7540)