alphaglosined

I created the D version of the value type exceptions proposal.

In the end, it was DOA due to compiler architecture, so that was the end of that beautiful design.

I've had to accept result types is about as good as its going to get, all that is missing to make them nice is unwrapping support in if statements. Which I too have a proposal for and implemented it. But alas politics.

It is more widespread than you may realise.

That work contributes to static analysers' data flow analysis algorithms and is very widespread, even if it's in a limited capacity.

C#, gcc, clang, and even dmd, with my fast DFA engine, utilise it.

We can't all be using Astrée, far too expensive ;)

Getting a web framework into the standard library is something I want to get working, along with a windowing library.

Currently we need to get a stackless coroutine into the language, actors for windowing event handling, reference counting and a better escape analysis story to make the experience really nice.

This work is not scheduled for PhobosV3 but a subset such as a web client with an event loop may be.

Lately I've been working on some exception handling improvements and start on the escape analysis DFA (but not on the escape analysis itself). So the work is progressing. Stackless coroutine proposal needs editing, but it is intended to be done at the start of next year for approval process.

Indeed the GC is just a library with some helpful language hooks to make the experience nice.

If you understand how it's hooked into, it's very easy to work with. There is only one area of the language related to closure context creation that can be unexpected.

Ldc like dmd ships lld and mingw import libraries and has for a few years now.

They both work out of the box without MSVC installed.

It's only ImportC feature that requires MSVC. The work required to get clang working in its place hasn't happened yet.

The following statement originates from Adam Wilson who is heading the PhobosV3 project, and I will second it.

The issues you have are examples of known problems that PhobosV2 has suffered under. Coroutines, for instance we would like to have in language, a proposal (me, not Adam) have already made one, but it's sitting till next year. Naming and interfaces issues are a big part of what will change in PhobosV3.

Are you talking about "Issue 24254 - LDC crash on Epyc Bergamo"?

That was fixed within the week, with a notification given that it had been sent to the reporter.

LLVM can do an awful lot with SIMD that isn't visible in clang.

We have experienced this with LDC in D.

What I've been told is that LDC produces better IR than clang (I haven't compared, I only know that LDC is practically magical from both mine and other peoples experiments).

About the only thing I've seen that has problems with inlining is inline assembly. Intrinsics are fine (which you don't need thanks to vectorization being practically magical as long as you do some annotations like assert and get the memory layout right).

About a year ago I had a look at a C compiler for 16bit computers, featured in disk form on I think Adrian's digital basement YT channel.

The compiler was very basic, nothing like you'd expect from a compiler even from the dragon book.

So simple and it was a production compiler too!

Sadly I can't remember the name of it to reference here.

Memory safety is broken up into a bunch of different categories. It isn't just one feature.

Yes D uses the GC for lifetime issues currently, but it does not need it for doing bounds checking, escape analysis or preventing common issues surrounding pointers. All of which are very useful things to have with or without the GC.

Just those features alone would prevent some pretty big name issues that have cropped up in C code over the years.

I'm one of the moderators on D's Discord server.

We do our best to ensure everyone feels welcome to join in. Of course none of us have social media training and are just doing our best.

If something is going down and we are not taking action it may be because we are not aware of it being problematic and are always open to hearing complaints as they come up!

But only for structs.

We really need to get actual reference counting into the language to cover classes properly as well.

It has been on my todo list to write a DIP for this for a while now. ~rikki.

Unless you are touching something like threads or exceptions, you probably won't use classes unless it expresses your data best.

So yes, perfectly usable without OOP or classes.

Audio plugins like VST.

He created dplug, a framework for audio plugins in D a pretty great feat!