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