On Saturday, 4 February 2023 at 19:49:41 UTC, bachmeier wrote:
> I'm not sure what Adam's getting at when he says "hopelessly broken" but it's basically a subset of D.

You're almost guaranteed to hit some wall with it and have no solution. Some of these are bugs but some of them are by design; betterC is a set of arbitrary restrictions without much consistent reasoning behind them.

For example, with dlls, you still have to deal with all the potential problems of C library version mismatches, but if you use any module that touches a D feature it is likely to compile but then fail to link when someone uses it! All pain, no gain.

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.

On 05/02/2023 1:20 PM, Adam D Ruppe wrote:
> 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.

This only affects you if you use full D to interact with -betterC code.

Even then it is very easy to work around.

https://github.com/Project-Sidero/basic_memory/blob/main/source/sidero/base/moduleinfostubs.d

-betterC DLL's do work with full D executables.

If all you need it for is gluing some stuff together don't listen to Adam about it not working, because it absolutely does and quite usable if you're not expecting there to be a GC.

On 05/02/2023 10:01 PM, Tamas wrote:
> On the surface, betterC seems to be perfect for this case. How would YOU do it (Adam, Richard)?
> 
> BtW, gstreamer also has D bindings, and maybe in the future I'll use those. I suspect that Adam's suggestions have a stronger relevance to that case, right?

So LDC with druntime and yes GC turned on is good enough right now that you can probably make it work without too much effort. You don't necessarily have to limit yourself to -betterC.

In fact if you don't, you have access to PyD[0] which can handle the interop stuff for you. I haven't personally used it, but it might work for your use case :)

The main thing is no matter what flags you pass, you'll need to be careful about memory ownership between the language divide and the ownership therein. You have already got a hang of that though from the C version! Just gotta be extra careful with GC memory that its pinned on the D side and won't get free'd elsewhere.

But yeah if you can avoid having to create bindings for stuff (such as glib which we have bindings for), or wrappers ext. do so. That way you can do more of the fun things!

[0] https://github.com/ariovistus/pyd

On Mon, Feb 06, 2023 at 03:54:40PM +0000, bachmeier via Digitalmars-d-learn wrote:
> On Sunday, 5 February 2023 at 08:48:34 UTC, Tamas wrote:
[...]
> > This is the specification for the D Programming Language.
> 
> I've been bitten by that a few times over the years, though to be honest, I'm not sure of the relationship of the spec to documentation. The Phobos documentation and compiler documentation appear to be actual documentation, in the sense that you can trust it to be accurate, and if not it's a bug.  Maybe someone that has been around from the earliest days understands the goal of the spec.

IIRC the spec was started as part of an ongoing effort to fully specify the language so that, at least in theory, someone could read the spec and implement a D compiler completely independent of the current ones.


T

-- 
INTEL = Only half of "intelligence".