www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - betterC becoming unusable

reply Steven Schveighoffer <schveiguy gmail.com> writes:
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)
Nov 06 2022
next sibling parent Dave P. <dave287091 gmail.com> writes:
On Monday, 7 November 2022 at 03:59:28 UTC, Steven Schveighoffer 
wrote:

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

 [...]

 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.

 [...]




This one drives me nuts. At least one scenario that causes it: 
https://issues.dlang.org/show_bug.cgi?id=22427
Nov 06 2022
prev sibling next sibling parent reply zjh <fqbqrr 163.com> writes:
On Monday, 7 November 2022 at 03:59:28 UTC, Steven Schveighoffer 
wrote:

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

 They encountered 2 problems:



I think D has several directions, but it is definitely worthwhile 
to enhance `Better C`.
If `BetterC` can make full use of the standard library in the 
aspect of `embedded/small memory system development`, it will 
surely attract `many people`.
I want to know how many `modules` of the standard library are 
compatible with `BetterC` now.
Nov 06 2022
parent reply Imperatorn <johan_forsberg_86 hotmail.com> writes:
On Monday, 7 November 2022 at 06:05:50 UTC, zjh wrote:

 On Monday, 7 November 2022 at 03:59:28 UTC, Steven 
 Schveighoffer wrote:

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

 They encountered 2 problems:



 I think D has several directions, but it is definitely 
 worthwhile to enhance `Better C`.
 If `BetterC` can make full use of the standard library in the 
 aspect of `embedded/small memory system development`, it will 
 surely attract `many people`.
 I want to know how many `modules` of the standard library are 
 compatible with `BetterC` now.


I'm also in favor of "fixing" betterC because of similar reasons
Nov 07 2022
parent reply zjh <fqbqrr 163.com> writes:
On Monday, 7 November 2022 at 09:12:51 UTC, Imperatorn wrote:


 I'm also in favor of "fixing" betterC because of similar reasons


There are several `betterC` container libraries. If they are 
integrated into the `standard library`, it would be cool. With 
the powerful template function, they are not much worser than 
`C++`.
If the `'C++'` is well interfaced, it is really cool.
Because `C++` has several inherent defects. `betterC` can be more 
comfortable.
C++'s shortcomings is that you have to use `ugly macros` anyway.
while `'rust'` has ugly syntax, unnecessary wordy lifetime, 
dependency hell, and slow compilation speed.I don't Why do these 
people like `it`?
Nov 07 2022
next sibling parent Imperatorn <johan_forsberg_86 hotmail.com> writes:
On Monday, 7 November 2022 at 09:35:25 UTC, zjh wrote:

 On Monday, 7 November 2022 at 09:12:51 UTC, Imperatorn wrote:


 I'm also in favor of "fixing" betterC because of similar 
 reasons


 There are several `betterC` container libraries. If they are 
 integrated into the `standard library`, it would be cool. With 
 the powerful template function, they are not much worser than 
 `C++`.
 If the `'C++'` is well interfaced, it is really cool.
 Because `C++` has several inherent defects. `betterC` can be 
 more comfortable.
 C++'s shortcomings is that you have to use `ugly macros` anyway.
 while `'rust'` has ugly syntax, unnecessary wordy lifetime, 
 dependency hell, and slow compilation speed.I don't Why do 
 these people like `it`?


I don't know why people "like" Rust. But let's not think about 
that and focus on improving D instead 😎
Nov 07 2022
prev sibling parent reply Paulo Pinto <pjmlp progtools.org> writes:
On Monday, 7 November 2022 at 09:35:25 UTC, zjh wrote:

 On Monday, 7 November 2022 at 09:12:51 UTC, Imperatorn wrote:


 I'm also in favor of "fixing" betterC because of similar 
 reasons


 There are several `betterC` container libraries. If they are 
 integrated into the `standard library`, it would be cool. With 
 the powerful template function, they are not much worser than 
 `C++`.
 If the `'C++'` is well interfaced, it is really cool.
 Because `C++` has several inherent defects. `betterC` can be 
 more comfortable.
 C++'s shortcomings is that you have to use `ugly macros` anyway.
 while `'rust'` has ugly syntax, unnecessary wordy lifetime, 
 dependency hell, and slow compilation speed.I don't Why do 
 these people like `it`?


Mostly because it is an ML inspired language with C++ like 
capabilities, a cool type system, but above all, it doesn't 
matter how it looks, because a bunch of big corporations decided 
it was going to be their C++ replacement, and it already powers 
part of Android, AWS and Azure.

Just like I am not a big Go fan, yet due to CNCF products, it 
landed on my plate as well.
Nov 07 2022
parent zjh <fqbqrr 163.com> writes:
On Monday, 7 November 2022 at 13:19:25 UTC, Paulo Pinto wrote:


 Mostly because it is an ML inspired language with C++ like 
 capabilities, a cool type system, but above all, it doesn't 
 matter how it looks, because a bunch of big corporations 
 decided it was going to be their C++ replacement, and it 
 already powers part of Android, AWS and Azure.

 Just like I am not a big Go fan, yet due to CNCF products, it 
 landed on my plate as well.



when at work, that's ok. but aside of that, I think it's better 
to learn a language you like.
I don't know anything about `ML`.
The strategy of `big` company is to `follow`, they don't like 
innovation.
Nov 07 2022
prev sibling parent reply rikki cattermole <rikki cattermole.co.nz> writes:
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)!
Nov 07 2022
next sibling parent rikki cattermole <rikki cattermole.co.nz> writes:
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.
Nov 07 2022
prev sibling next sibling parent reply Paul Backus <snarwin gmail.com> writes:
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.
Nov 07 2022
parent reply Alexandru Ermicioi <alexandru.ermicioi gmail.com> writes:
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.
Nov 07 2022
parent Paul Backus <snarwin gmail.com> writes:
On Monday, 7 November 2022 at 12:46:08 UTC, Alexandru Ermicioi 
wrote:

 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.


I agree, but changing the headers in core.stdc now would break a 
lot of existing code, so I don't think it's likely to happen.
Nov 07 2022
prev sibling parent Steven Schveighoffer <schveiguy gmail.com> writes:
On 11/7/22 4:50 AM, rikki cattermole wrote:

 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.


Yes, it's the template that is not being emitted. Whatever the reason, 
it's unacceptable.


 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)!


An array comparison is an array comparison, regardless of element type. 
I want to see if my array of code units is exactly the same as another 
array of code units. I don't care about sanitization because that's not 
what I'm asking for. I don't need unicode tables to tell me if "4.2.0" 
is the same as "4.2.0".

This focus on unicode is a complete distraction, pretend it's a byte 
array, same problem.

-Steve
Nov 07 2022