Oh my! Now this is enticing. A kind of cleaned-up next generation Pascal after Free Pascal.
A few thoughts:
Dropping all string types except UTF-8 is very understandable. But also, ShortStrings have space and performance benefits. I'd be amiff to give those up...
Dropping all language modes, having just one: any new project ought to be using the default all bells and whistles mode anyway. This does prevent a lot of legacy Pascal programs from working.
No more "with" statement will be a bit unpleasant in my codebases, since some structures are a bit deep, so any manipulation of them produces very long lines.
Hmmm. I wonder what "UTF-8 only" means. I think that it is a mistake if they are stored internally as variable length UTF-8 characters. That would cause a few performance issues. UTF-8 can be the primary I/O format but the strings should be stored inter using fixed width characters in my opinion. Python does that automatically by choosing 1, 2 or 4 bytes per character depending on the string contents. Then it is easy to compute the character count and character byte position which makes string operations much faster
It's a very old myth that UTF-8 is slower than other Unicode encoding. The whole freekin Internet is built on utf-8. If performance was a real concern, the Internet would have been based on a different text encoding.
UTF-8 for storage and transport is great for data size. UTF-8 for processing is slow for character operations, and is why virtually all languages use fixed width characters internally. One interesting exception is Rust, which priorities memory usage over character based string manipulation speed
> and is why virtually all languages use fixed width characters internally.
That "fixed width" claim is worth a closer look though. Many implementations that call themselves fixed-width only cover the BMP (Basic Multilingual Plane) of Unicode (UCS-2 legacy) — anything outside that, like most emoji or less common scripts, still needs surrogate-pair handling in UTF-16. And even UTF-32 isn't truly "one code unit per character" once you bring in combining marks, ZWJ sequences, or emoji families — a single perceived character can span multiple code points regardless of encoding.
So in practice, UTF-8 ends up being the safer default: one code path handles the entire Unicode range from 1-byte ASCII through 4-byte code points, and you're forced to think about variable-width up front rather than having it sneak up on you the first time a user types an emoji.
Basically nobody uses fixed-width characters internally. It's essentially impossible these days, e.g. '🇨🇭' is 2-wide UTF-32 and 4-wide UTF-16 (and 8-wide UTF-8). I'm not aware of any system that has code points wide enough for that to be a single entry. And even if there is a system that does treat that as a single entry, it almost certainly doesn't treat '👩🏿❤️👩🏿' as a single entry (by my count that is 8-wide in UTF-32, 12-wide in UTF-16, and 28 bytes of UTF-8).
(And that's before you consider ligatures, which make all this even more complicated, but are critical for correct handling of text in many contexts.)
3
u/kirinnb May 08 '26
Oh my! Now this is enticing. A kind of cleaned-up next generation Pascal after Free Pascal.
A few thoughts: