rval->ref const(T), implicit conversions

[Manu via Digitalmars-d]

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.