rval->ref const(T), implicit conversions

[Meta via Digitalmars-d]

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.