alphaglosined
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.
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 ;)
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.
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.
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 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.
That was fixed within the week, with a notification given that it had been sent to the reporter.
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).
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.
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.
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!
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.
So yes, perfectly usable without OOP or classes.
He created dplug, a framework for audio plugins in D a pretty great feat!
Lots of stuff exist specifically to help with onboarding people into the community. Like the recent announcement of adding a C parser into the frontend.
Following that you will want to check for null ext. to make it actually @safe in practice and not just typed as such.
You can also get soft copies (i.e. mobi, pdf) and the docs as part of the d-apt repository for debian.
Depending on the nature of distribution it is probably just in a different package (or the package maintainer needs yelling at).
It was created based upon real world experience having designed and implemented it in D. Where all of your concerns have not been discussed in the years following that article (it was already in the language for about 8 years at that point aka the start and has been solidly proven to work in the exact same context as it would have done in C).
In D at least, you can grab the pointer by a simple .ptr and for length .length. To get a specific element, it is as you would expect &f[i] all nice and straight forward. But what if you want to create an array from malloc? In D that is easy, just slice it! malloc(len)[0 .. len]. And free is just as you would expect from above, free(array.ptr);