UTF-8 Unicode operators vs digraphs
Dlighted
test at example.com
Tue Aug 11 17:34:00 UTC 2026
The site told me I should make a new thread rather than replying
to a years old one. Forgive me if I made a completely useless
offtopic thread that wasted everyone's time.
I thought about Unicode operators multiple times over the years
and it's been mentioned on the D forum more than once:
https://forum.dlang.org/thread/nujfnoneihykkkfzeeaj@forum.dlang.org
https://forum.dlang.org/post/ahxrzlvznpdutwvvmlfv@forum.dlang.org
I think especially digraphs like >= <= != are a relict of the
past.
They are stand-ins for ≥ ≤ ≠ just like C has for many other now
common symbols. I'm supposed to do mental gymnastics and visually
overlap the symbols to see the actual symbol.
Until C23:
??= #
??/ \\
??' ^
??( [
??) ]
??! |
??< {
??> }
??- ~
Since C 95:
<: [
:> ]
<% {
%> }
%: #
https://en.wikipedia.org/wiki/Digraphs_and_trigraphs_(programming)
Keeping the old for compatibility and ease of typing makes sense
but it doesn't really make sense to force the old ones.
Is != /= ~= -ne <> really better than ≠? (Okay, I haven't used
Haskell yet. I'm strawmanning.)
The Julia programming language supports all the Unicode math
symbols. Maybe a step to far since programming and math are
different.
Personally I can in fact type some math symbols on my keyboard
layout natively on higher layers without using compose. ¬ ∨ ∧
And every Linux user (like me) can use xcompose by pressing the
compose key or shortcut. My xcompose also has some already
predefined. >= <= /= turn into ≥ ≤ ≠.
There are also third party keyboard layouts and IMEs for Windows.
I have used one and it worked fine.
Maybe code formatters could convert to them too.
Implementation:
Many languages now standardize on UTF-8. UTF-8 has conquered the
world and everything else is legacy baggage.
There is exactly **one representation** for these old 1993
Unicode symbols in UTF-8.
It's a sequence of three bytes forming one codepoint.
Even if you don't want to deal with code points or graphemes,
**it is no different than implementing a C trigraph** to my
understanding. It should not matter if the byte holds an ASCII
value or a value outside that range.
So in UTF-8 ≤ is a trigraph of 0xE2, 0x89, 0xA4. It's easier than
actual digraphs or trigraphs because ≤ can't be part of something
else due to the way UTF-8 was designed. The only question I have
is why we haven't done it yet.
Personally I find && quite ugly too. ∧ ∨ for && || are more
readable. I know Walter doesn't like the keywords _and or not_
because they've been used as variable names. I read it somewhere
on the forum. But I guess that would be too controversial for
people who don't know math well. I actually like the words but I
use a Germanic language, so I'm naturally biased whereas math is
universal.
However the symbols ≥ ≤ ≠ would be an undeniable upgrade. So, uh
... **Why not?**
---
https://forum.dlang.org/post/u571i2$1bv3$1@digitalmars.com
On Wednesday, 31 May 2023 at 08:47:04 UTC, Walter Bright wrote:
> I use putty a lot to access computers remotely in text mode.
> With some experimentation, some Unicode characters are
> rendered, but some aren't, like the 69 quotes. Maybe the
> programming world isn't quite ready for them yet.
He probably didn't use Cygwin. Console applications (especially
cmd.exe) have loads of problems on Windows without
https://cygwin.com/
With Cygwin everything always ran fine for me without Unicode
issues.
The new Windows Terminal might also work.
https://apps.microsoft.com/detail/9n0dx20hk701
The old Windows parts will always be like this. It's a frozen
museum. You gotta let go. Change habits.
However all modern parts of it shouldn't have any problems at
all. And those 1993 math symbols are covered by fonts on every
system today.
Those math symbols are only one code point. They work even in
relatively ancient software that has problems with emojis such as
Notepad++ and other scintilla engine based text editors.
More information about the Digitalmars-d
mailing list