On Monday, 18 January 2016 at 15:36:09 UTC, Manu wrote:
One more time...
Assuming:
void func(const CustomString &s1, const CustomString &s2);
void func(ref const(CustomString) s1, ref const(CustomString)
s2);
C++:
func("hello", "world");
D:
auto dumb_name = CustomString("hello");
auto another_dumb_name = CustomString("world");
func(dumb_name, another_dumb_name);
I _hate_ this. Almost every line of my current project's
non-systems
code looks like this.
The majority of the code I'm working with is event handlers and
glue
logic, which looks like this. Tons of 1 liners and glue. D code
is
much larger by volume, and much less readable than C++. The
statement
above has about a 1/8 signal to noise ratio, and this is
actually
understated; I have a lot of functions that take 4 strings like
that!
This problem extends well beyond strings, but it's a classic
example.
The main advantage of D is modules, slices, forward referencing
and compile times, but I'm seeing trade off of much less
efficient code density/brevity for those advantages. D has a
meta advantage, but I'm writing C++11/14 code now which is
*almost* sufficient, so that advantage is quite diminished in
2016.
In general, I'm finding it hard to do anything useful in this
project
without C++ style implicit conversions. Compared to C++ code,
I'm
finding D becomes riddled with explicit constructor calls and
terrible
stack variable names where C++ implicit construction/conversion
would
normally kick in.
This becomes more awkward in some generic function situations,
but
it's especially painful (queue broken record) passing such
rvalues to
ref-args.
There is truly nothing else in D that has caused so much
unrelenting
grief as not being able to pass an rvalue to ref const(T). If
we are
never to get a scope-like solution, then consider supporting
C++ style
rval->const ref, as a pure practicality. It's been long enough,
like,
7 years or something I've been waiting.
So, where are we heading with this? I raise this a couple of
times a year. In 6 years, after a lot of talk (and various
rejected proposals), as far as I can tell, we aren't any closer
to a plan.
In my experience, this has always been and remains the biggest
practical annoyance writing D code, _by far_. It affects a very
high
number of my lines of code, of all kinds.
What I don't get is, why does this seem to be unique to me?
Perhaps
it's because one common thread among almost all my D
applications, is
that I'm working together with C/C++. I can't transition to D
unless I
can work effectively against existing/established code. That's
all
I've been trying to do for this past 6-7 years, and I'm yet to
successfully produced an acceptable transition path in my years
of
trying. This remains a very significant contributor to that
failure.
How are we going to resolve this?
Nobody will want to transition if their code gets plainly
worse, from
a basic practical standpoint.
There was this pull request which implemented `auto ref` for
non-template functions:
https://github.com/D-Programming-Language/dmd/pull/4717
But it was closed. I can't remember the exact reason why.
