"H. S. Teoh via Digitalmars-d" wrote in message
news:[email protected]...
It depends on how we do the transition. If we replace dmd with ddmd
first, then we'll run into problems with Phobos adoption, because we may
discover that using Phobos causes (d)dmd to be unacceptably slow /
bloated / etc., which means it becomes a disincentive to use Phobos in
ddmd.
There is no if, this is exactly how it is going to happen. Phobos will not
be used in ddmd until after the transition.
But another way to approach it, is to do Phobos integration first, while
we still have the current C++ code. We may discover that ddmd becomes
unacceptably slow -- but since all of us want to make D self-hosted,
this is great incentive for improving Phobos so that ddmd is *not* slow.
While we work on fixing Phobos, we still have the current C++ dmd to
serve user needs. Then when Phobos is finally no longer slow/bloated in
ddmd, we can transition to ddmd and have a compiler on par or even
better than the C++ dmd.
No. If you want to improve phobos, make phobos quality a blocker for your
own projects, don't screw over ddmd.
Well, I don't think anyone is going to *force* you to do that, this
being a volunteer project and everything. :-) What about recruiting new
contributors who can help out?
Again, let's not make a phobos problem a dmd problem.
Not necessarily. If the compiler doesn't use the parts of Phobos that
has the new attribute, then it's not a problem.
Maybe, but I'm not so sure it will be that easy.
Another solution (albeit uglier) is to use version(...) in Phobos to
suppress certain new features if the current compiler is known not to
support it:
That's somewhere between horrific and unacceptable. It's just not worth it.
I think this should be possible using static if (__VERSION__ ...).
Possible but not worthwhile.
