On Wednesday, 8 December 2021 at 13:19:52 UTC, bauss wrote:

Thousands, plural :) 3076 open reports for dmd alone at this time, if I'm reading bugzilla correctly.

On Wednesday, 8 December 2021 at 13:19:52 UTC, bauss wrote:

It's easy to get that impression when you wrote:

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".

Do you have a bugzilla issue, or are you referring to liberal use of GC allocations in druntime/Phobos?

It works well when translating C code to D, which was its intended use case. 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.

This year there actually has been lots of progress in eliminating those bugs, e.g.:
Fix issue 17977 - destructor allows escaping reference to a temporary struct instance
Fix Issue 22366 - [dip1000] scope variable can be assigned to associative array
Fix issue 20245 - address of ref should be scope
Fix issue 21912 - delegate assigned to return scope variable needs closure
Fix Issue 20150 - -dip1000 defeated by pure

I aggregated the remaining ones here: https://github.com/orgs/dlang/projects/4/

On Wednesday, 8 December 2021 at 13:13:05 UTC, Guillaume Piolat wrote:

I disagree in my turn. There is a clear pattern: a new cool feature is introduced; people try to use it but give up because the feature is half-implemented/buggy; then, a few years later, the feature gets deprecated because "nobody used it".

On Wednesday, 8 December 2021 at 14:30:46 UTC, Max Samukha wrote:

I struggle to find an example honestly?

There used to be such early bumps with UDAs or nothrow, or ranges.
For a decade or so, arrays ops simply crashed DMD with optimizations on. Now they work. Brings value for the daily D programmer actually.

Again I was a big user of builtin complexes, and loudly compagined against their removal.
When removal day came, it was very little work and worked without penalty or adverse effect.
So in the end the D core team was right not to listen to me... and now it is argued on the D forums that complex numbers were removed as if it was a bad thing and people were impacted. Well, no, was a good change.

On Wednesday, 8 December 2021 at 14:20:44 UTC, Dennis wrote:

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.

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.

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

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!

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.

On Wednesday, 8 December 2021 at 12:05:16 UTC, bauss wrote:

It would be nice if at least there was a plan to implement basic things like type unification. (binding parametric names)

On Wednesday, 8 December 2021 at 15:42:05 UTC, Stanislav Blinov wrote:

True, but it's best to avoid exaggeration if you don't want to be misunderstood.

Also true, I just think that being hyperbolically negative and blaming the attitude of D's contributors is unfair. There's plenty of people fixing bugs in existing features (just look at the changelog of new releases), but sometimes it's hard to keep up, and other times it's impossible to 'finish' things. CTFE started as a simple extension to constant folding, but nowadays some D programs do very complex things with it, hitting limitations and getting compile-time performance problems. That's not because the implementation of CTFE was abandoned 80% through in favor of a new shiny feature, it's because there was never a clear 100% to begin with, it's ever evolving.

On Wednesday, 8 December 2021 at 21:04:36 UTC, Dennis wrote:

I don't think anyone in particular is being blamed, but there is a mismatch between the chosen compiler architecture and an evolutionary development model. Evolution demands a more modular approach, and frankly, a constant reevaluation of the architecture with planned refactoring.

That's probably true for a lot of things, also things like inconsistencies and limitations of alias probably started as a quick add-on, but there is a limit to how far you can go with just evolution. If one keeps on evolving without redesigning then one ends up painting oneself into a corner where completion becomes an intractable proposition.

The most sensible thing then is to start remodelling into layers where you have a chance. The obvious starting point is to put a layer between frontend and backend. But then you have to make it a priority. Projects like @live and importC are rather ambitious. For importC you basically need to do like clang and implement the commonly used gcc extensions. Doing all of that at the same time pushes the finish-line far into the horizon. And then it is of limited use, even though a well developed @live analysis stage might be useful for analysing C-code and could possibly make some C-code accessible as @safe.

Maybe D should do like C++ compilers and set up page with hatch-marks for feature completion. I don't start using next generation C++ or JavaScript without checking those feature tables for 100% completion.

For many contexts of serious software development having a half-baked feature is almost the same as not having it at all.

On Thursday, 9 December 2021 at 00:19:19 UTC, Ola Fosheim Grøstad wrote:

May be you need a reconstruction DIP.

On Tuesday, 7 December 2021 at 16:43:21 UTC, ManKey wrote:

ldc2 test.i -mixin="test.d"

Write your transpiler!