betterC DLL in Windows

[Adam D Ruppe]

On Saturday, 4 February 2023 at 18:40:51 UTC, Tamas wrote:
> I do take your word for it, but now I have to re-evaluate my 
> expectations towards D and perhaps use it for another project. 
> I've got most of my project working in C already, but I was 
> hoping to add some safety and better readability/managability 
> by using some of the convenient features D offers over C.

This is achieved without the betterC switch, and severely limited 
with it.

> Also, your words give me the impression that I cannot trust the 
> documentation; which isn't a great start into the learning 
> process.

There's a lot of things described in the documentation that don't 
actually work. D can be an *extremely* productive language if you 
know which parts to focus on, but most the newer hyped features 
just don't deliver.

The table of contents on the left side of the site is in roughly 
chronological order. The things near the top are pretty reliable, 
with a few exceptions (which are generally called out in the 
documentation if you read it carefully, like how the "static 
initialization of associative arrays" is "not yet implemented", 
or misuse of shared is "is not an error yet by default").

The things near the bottom are not reliable. The C++ interface 
works in some cases but you aren't likely to get far using it in 
any real world project; the C++ stdlib bindings are extremely 
minimal and Windows-only. The Objective-C interface works 
beautifully on dmd.... which cannot target the new Apple devices. 
ldc can generate code for those arm chips, but the Objective-C 
interface is not implemented on ldc.

The portability guide and named character entities are pretty 
much ok.

The memory safety `@safe` stuff only actually works if you 1) opt 
into it in the functions and 2) opt into it on command line 
params. This is mentioned in the docs as a small note near the 
bottom. The design of @safe also allows several things that can 
escape it on certain systems.

The ABI page is ok, but there are several bugs in the debug info 
output. I find it good enough but it can be annoying.

The vector extensions work on dmd if you can piece together the 
magic but the other compilers do it differently.

The betterC page has several falsehoods on it, including the 
misinformation that you need to use it to link into C 
applications. This is just 100% nonsense. It also claims nearly 
the full language remains available, but this is also simply 
false. Some of the things listed there can be made to work with a 
bunch of code, but many things just plain don't work, even if you 
add the small amounts of code necessary to enable them.

For example, interfaces don't work, even if you implement your 
own dynamic cast function. It just doesn't let them link. It 
claims constructors and destructors work, which is true, unless 
they're `static`, in which case you get random errors. Delegates 
and lambdas work if you manage captured variables in your own 
functors, but otherwise are simply disabled, even if you had your 
own backing system.

Even module imports can fail because betterC disables outputting 
the module data info, even if it would otherwise be required by 
language rules, despite it not using the druntime.

Then importC only works for toy examples. Using two separate 
headers or modules will result in spurious compile errors (and 
bugs detailing how to address this have been closed WONTFIX), and 
there's several kinds of C apis it just doesn't support.

And finally, the @live functions also only work in toy examples 
and the design is fundamentally limited to only direct function 
calls, no struct aggregation is supported at all. It is a 
complete dead end.

On the other hand, if you avoid most the compiler switches and 
stick to the more solid features - "Interfacing to C" and above 
on the list, for the most part - you'll find D is a very capable 
conservative language.