On Monday, 16 July 2012 at 06:00:03 UTC, Walter Bright wrote:
Supporting Win64 is absolutely critical for the future of D,
and the sooner we get it, the better. The COFF route is the
shortest route to doing it, and the most practical for
attracting devs, which is why it's the way we're going.
Sorry, but I don't think this is a valid argument. Yes, Win64
(and even more so, COFF) support is important to have for DMD,
but no, it's not a good idea to delay a pending release because
of this (cf. the »Time for a new beta« thread from the end of
May). Here is why:
http://d.puremagic.com/issues/buglist.cgi?chfieldto=Now&query_format=advanced&chfield=bug_status&chfieldfrom=2012-04-13&bug_status=RESOLVED&resolution=FIXED
Already 289 issues resolved since 2.059!
And implementing Win64 support isn't going to be done in a
weekend. Sure, the changes needed are not world-shattering:
Finish COFF writing support, tweak the register spilling/call
emitting code to conform to the Win64 ABI, implement vararg
support in both the backend and druntime (they are handled
differently on Win64 than described in the System V ABI),
transition to the MSVC runtime. druntime and Phobos will also
require some changes, although there shouldn't be much left to
do, given that GDC (and LDC, except for exceptions) already work
on x64 Windows.
After this has been done, there are still
http://d.puremagic.com/issues/buglist.cgi?chfieldto=Now&query_format=advanced&chfieldfrom=2012-04-13&bug_severity=regression&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED
to deal with. And after those regressions have been fixed and a
first beta is released, chances are that some new regressions
will pop up, because many people can't even use Git master for
their real-world code right now.
So, all in all, I wouldn't expect a release before, say, around
mid-September. This is five months after the last release, a
delay twice as long as our usual release cycle. Several of the
bugs fixed since 2.059 were hard to work around, so I don't think
it's unreasonable to assume that we will have lost users because
of this. And what for? Chances are that we will just have _two_
semi-working targets in DMD then (structs are still broken on
x86_64 Linux/OS X/BSD w.r.t. parameter ABI and in some cases
sizing/alignment).
If you really want to make D more attractive, including for
corporate use (from what I gathered from several Thrift-related
discussions), the easiest thing to do, in my humble opinion,
would be to make the release schedule at least somewhat
predictable, to publish more or less dependable short-term
roadmaps, and most importantly, to actively communicate your
decisions on these topics – it just happens that you are D's
lead-developer-release-manager-strategist-dictator, regardless of
whether you'd prefer to fill only some of the roles.
David
