On 10/6/2017 1:39 PM, Laeeth Isharc wrote:
Perception is so important when people are making decisions about something they
don't know. (As Walter says, you have to write tens of sloc in a language to
really see it's benefits. They won't be so evident if you write D like the
languages you know).
I've nearly finished converting the Digital Mars C++ front end from C++ to D.
Amusingly, it looks line-for-line almost identical to C++ (the biggest change
being exchanging "->" for "."). But I deliberately made as few changes as
possible, because if I introduce a bug doing that, it will be much easier to
find by comparing the C++ source with the D source.
To aid in this, I do it function-by-function, running the test suite after each
function is converted. The idea is to use `git bisect` to isolate any conversion
bugs not covered by the test suite.
So the end result has all the flaws of the C++ version. But once in D, I can
start taking advantage of D (like nested functions) to structurally improve it.
It'll always show its C++ inheritance, though.
So I think the GC series has been very helpful.
But it might also be helpful to be very explicit on the functions that can and
can't be called with nogc (I mean a top level overview in the docs) because it's
one of the remaining sources of FUD that people say "yeah but you can't use
large parts of the standard library without the GC".
And for things that are useful and easiest done with GC it would be nice to have
an alternative that doesn't depend on the GC - if for no other reason than to
address objections. So the answer is then "yes - you're right, these X
functions depend on the GC, but there are similar ones that don't". (Walter
already started that for functions that use the GC for purely legacy reasons but
I mean for more difficult cases too. I know Weka wrote their own versions of
some std.algorithm functions for example). Many things aren't much work, but
when you have a lot to do, even small frictions can have big consequences.
So it's also a documentation question - it's not that easy from the outside last
time I looked to see just how easy std.experimental.allocator is to use.
One of the motivations for -betterC is to make D usable without any reliance
whatsoever on the D runtime library, including the GC. You still get a long list
of benefits from using D over C++. (The translation above is relying on -betterC.)
