How to convert C to D using compiler?

[Stanislav Blinov]

On Wednesday, 8 December 2021 at 14:20:44 UTC, Dennis wrote:
> On Wednesday, 8 December 2021 at 13:19:52 UTC, bauss wrote:
>> I never said everything doesn't get finished.
>
> It's easy to get that impression when you wrote:
>
>> Nothing is ever completed or workable.
>
> And only specified afterwards that it's limited to 
> "ground-breaking features", which is a pretty big caveat by the 
> way. If I say "static/dynamic arrays, `scope(exit)` and 
> `foreach` work pretty good", then you could just reply "well, 
> those are not ground-breaking".

Come on, since when does a hyperbole require qualification? :) 
Surely he didn't mean literally "nothing".

Although, on the point of qualification, "work pretty good" is a 
far cry from "work, period". Static/dynamic arrays don't "work, 
period" as soon as copy constructors get involved. Which is a 
new-ish feature, by D standards. One that is recommended to 
switch to by the documentation, while the language and its 
runtime aren't actually able to support such transition. Which 
emphasizes bauss' point.
Yes, this is reported on bugzilla and is being slowly worked on. 
But that means one has to know the current caveats and work 
around them.

>> nogc is still too limited
>
> Do you have a bugzilla issue, or are you referring to liberal 
> use of GC allocations in druntime/Phobos?

212 open issues on bugzilla with search for 'nogc'. Cursory look 
shows some of 'em might have gotten fixed along the way though. I 
guess I've just volunteered myself to vet them.

>> betterC is still somewhat limited
>
> It works well when translating C code to D, which was its 
> intended use case.

Was it? Its documentation suggests that its intended use case is 
to integrate D code into existing code bases.

> It's when you start writing new -betterC code with D features 
> that you get cryptic/unnecessary TypeInfo errors, which makes 
> this an interesting case: it shows how things can be unfinished 
> not because the implementation doesn't match the requirements, 
> but because the requirements update, as people started using it 
> for e.g. WebAssembly / embedded purposes.

That doesn't alleviate the frustration one gets when faced with 
that particular error message :) I mean, for real, just adding an 
-inline flag might break a build, with not even a hint as to why. 
Bonus points for being able to reduce the issue for a bug report!

>> scope  has so many bugs/edge cases that hasn't been solved, 
>> making it unusable in general.
>
> This year there actually has been lots of progress in 
> eliminating those bugs, e.g.:

I've noticed you've been cracking hard on DIP1000, and the 
progress is great to see. I don't think anyone here wants to 
belittle the actual sleeves up work that is being done. But the 
general frustration is also pretty understandable. For example, 
one of the issues you've cited was 4 years old. And there are 
many, many more (not necessarily DIP1000-related) that date back 
more than a decade.