On Wednesday, 3 December 2014 at 15:52:30 UTC, Dejan Lekic wrote:
What are alternatives? - Make the abovementioned "stable D"
branch by yourself, and maintain it in-house.
Yes, I have started to replace phobos with my own library. It
will probably take a man-month to complete. The advantage is that
I get my own types for integers, simd and simd friendly
containers. The disadvantage is that you end up on an island…
This is exactly what people have done with C++ up to now.
But the real issue is the compiler. If I want to receive bugfixes
I will only be able to modify the compiler on the most
superficial level, which is the parser and some conditional
switches in strategic location in the compiler core (e.g. turning
off UFCS). That limits what you can do, but what can be done in
the parser is easy to fix, less than 2 weeks of work
So this is possible, but far from ideal IMO.
In perspective: C++ spent ~20 years getting a reasonable standard
library in place which has a more narrow scope than D's standard
library and C++ had to change the language to make STL usable
(and it still is annoying).
It is really hard to do all this in a truly open project
because maintaining this stable branch is IMHO a full-time job.
I don't think maintaining a stable branch is a full time job. The
maintainer will only back port bugfixes that are non-breaking
(i.e. you don't back port well known bugs with well known work
arounds).
The real challenge is to get to a stable release in the first
place, because that would probably require a 6 month feature
freeze.
To get a feature freeze you will have to get most people to agree
on the current feature set being sufficient, which is at odds
with the «please break my code» crowd.
What is really needed is a list of issues with assigned
priorities that has to be fixed before a feature freeze can be
decided on.
That will only happen if someone steps up and take a management
role where issues are identified, analyzed, prioritized and
followed up with a plan.
