I had a person who was trying to use raylib-d using betterC.

They encountered 2 problems:

1. raylib-d was using Phobos to construct enums or in template constraints. Things have bizarre errors at compile-time. Like `isRange!MapResult` (from `std.algorithm.map`) is false. Why? Because it's checking for some "does this compile" checks, and they fail because betterC disallows using things. Which things? I don't know, because all the error says is, it's not an input range [1]. Now, you might say "Too bad, you can't just can't use phobos anyway". But this is being attempted in CTFE. So I don't *actually need* to link the runtime (though I bet if it were allowed, it would still fail to link, due to CTFE-used functions still being emitted).

2. Array comparison sometimes fails to link. That's right `string1 == string2` may fail depending on whether the compiler decides that the support template in druntime needs to be emitted to the object file. This is unacceptable. If I have to use `strcmp` in betterC, I might as well just use C.

There are fundamental problems here. Ones that aren't easy to fix. Using betterC just seems to be a worse experience than either using D or using C. Is there any hope for fixing this?

-Steve

[1](https://issues.dlang.org/show_bug.cgi?id=23468)

On 07/11/2022 4:59 PM, Steven Schveighoffer wrote:
> 2. Array comparison sometimes fails to link. That's right `string1 == string2` may fail depending on whether the compiler decides that the support template in druntime needs to be emitted to the object file. This is unacceptable. If I have to use `strcmp` in betterC, I might as well just use C.

Lets dig a bit.

https://github.com/dlang/dmd/blob/master/druntime/src/core/internal/array/comparison.d

It is templated (so it should already be emitting correctly).

https://github.com/dlang/dmd/blob/master/druntime/src/core/internal/string.d#L239

Also templated.

But why on earth is UTF-8 strings specially cased and not UTF-16 or UTF-32?

Thats not right...

No sanitization, its basically just byte for byte comparison. Which is the wrong way to compare Unicode strings anyway (and requires the tables)!

After a bit of playing around, I think this is a template emission bug!

I cannot reproduce it, which leads me to think that -allinst might make it work.

On Monday, 7 November 2022 at 09:50:47 UTC, rikki cattermole wrote:
> But why on earth is UTF-8 strings specially cased and not UTF-16 or UTF-32?
>
> Thats not right...
>
> No sanitization, its basically just byte for byte comparison. Which is the wrong way to compare Unicode strings anyway (and requires the tables)!

https://dlang.org/spec/arrays.html#strings-unicode

> Note that built-in comparison operators operate on a code unit basis. The end result for valid strings is the same as that of code point for code point comparison as long as both strings are in the same normalization form. Since normalization is a costly operation not suitable for language primitives it's assumed to be enforced by the user.

Also, practically speaking, lots of D code uses `char[]` interchangeably with `ubyte[]` and does zero UTF-8 validation, especially code that interoperates with C libraries. So the idea that "D strings are unicode" is little more than a polite fiction.

On Monday, 7 November 2022 at 10:58:44 UTC, Paul Backus wrote:
> On Monday, 7 November 2022 at 09:50:47 UTC, rikki cattermole wrote:
>> But why on earth is UTF-8 strings specially cased and not UTF-16 or UTF-32?
>>
>> Thats not right...
>>
>> No sanitization, its basically just byte for byte comparison. Which is the wrong way to compare Unicode strings anyway (and requires the tables)!
>
> https://dlang.org/spec/arrays.html#strings-unicode
>
>> Note that built-in comparison operators operate on a code unit basis. The end result for valid strings is the same as that of code point for code point comparison as long as both strings are in the same normalization form. Since normalization is a costly operation not suitable for language primitives it's assumed to be enforced by the user.
>
> Also, practically speaking, lots of D code uses `char[]` interchangeably with `ubyte[]` and does zero UTF-8 validation, especially code that interoperates with C libraries. So the idea that "D strings are unicode" is little more than a polite fiction.

Doesn't mean that they are doing something right. They should just replace all char* with ubyte* in D for any C header they use, if they just simply cast them, then compiler could spot them when used with string only methods.

Best would be if such mixing between non utf and utf would not be so easy to do, and that would force user to think twice.