rvalues -> ref (yup... again!)

Manu turkeyman at gmail.com
Fri Mar 23 22:01:44 UTC 2018


Forked from the x^^y thread...

On 23 March 2018 at 12:16, Walter Bright via Digitalmars-d
<digitalmars-d at puremagic.com> wrote:
> On 3/23/2018 11:09 AM, Manu wrote:
>>
>> [...]
>
> Rvalue references are not trivial and can have major unintended
> consequences. They're a rather ugly feature in C++, with weirdities. I doubt
> D will ever have them.

Can you please explain these 'weirdities'?
What are said "major unintended consequences"?
Explain how the situation if implemented would be any different than
the workaround?

This seems even simpler than the pow thing to me.
Rewrite:
    func(f());
as:
    { auto __t0 = f(); func(__t0); }


How is that worse than the code you have to write:
    T temp = f();
    T zero = 0;
    func(temp, zero);

This 'workaround' is really upsetting. It's ugly, visually noisy, very
annoying to implement over and over, and litters the local namespace
with rubbish. There's no good name for most of this stuff, they just
get named t0, t1, t2...

Surely you can see how this objectively makes code worse...?
This one more than anything has made my work trying to convince people
that D is cool very hard. Most things I can explain around, or say
it's a known issue and it'll be better soon. This one is kinda harder;
"yeah... that's like, working exactly as intended! I know, isn't D
cool!" ;)


> But at some level, D cannot replace C++ on a line-by-line basis. There's
> always going to be something different. If not in the core language, in the
> way the standard library works. If you're heavily using templates and stuff
> in C++, you're likely going to have to rethink how the code works to get it
> in D (or any other language).

I haven't experienced much friction on that front, or had it expressed
by new users. They're generally willing to humour that D has
differences in it's meta, probably because they understand C++ sucks
and drastic changes must be made. They generally complain about choice
of '!' for a few minutes and then move on.
By contrast, people will NOT forgive the fact that they have to change:

    func(f(x), f(y), f(z));

to:

    T temp = f(x);
    T temp2 = f(y);
    T temp3 = f(z);
    func(temp, temp2, temp3);

That's just hideous and in-defensible.

A better story would be:

    func(f(x), f(y), f(z));
=>
    func(x.f, y.f, z.f);

Instead of being outraged, they'd be further seduced. Sadly, that's
not our reality (yet).
What a missed opportunity! ;)


> For example, in my efforts translating C to D, the clumsy part is the
> metaprogramming in the C preprocessor. There's nothing there D cannot do,
> but it has to be redesigned. The result is much better, but translating by
> rote is simply impossible.

I don't often work with C, and I think it's been considered pretty
unsavoury to lean heavily on the preprocessor for a few decades now.
Even if I did, I probably wouldn't 'port' C, so much as interact with
it, and extern(C) works well.
I'm more focused on C++, and as such, my experiences differ significantly ;)

Reworking a field of preprocessor cruft is in quite a different space
than "reworking all calls to func()".
People are forgiving of a thing if they appreciate and understand it.


> Also, just try translating some of the code in Phobos to C++. It was tried
> to do ranges for C++, and the result was terrifying. (It worked, but that's
> about all that could be said for it.)

I've done comprehensive slices and ranges in C++. It works reasonably
well. Certainly, the worst outcome was that I significantly diminished
any arguments I had to switch to D...

Not sure what your point is though? You'll find no argument from me
that slice, ranges, algorithms are awesome, and one of D's main
events... but new users need to get far enough into the woods to reach
that point.
We need to make sure we're the least amount likely to repel them prior
to reaching that point as possible.

I had a lunch discussion with a colleague today; he believes my claims
about ranges/algorithms and stuff, but he has no feel for it, and
can't really grok just how ground breaking that stuff is... he admits
he needs some experience to comment, and he's actively checking it
out.
It's critical that he doesn't try to call a function that takes a ref
before he reaches that moment, because if he does, chances are he'll
get angry at me for wasting his time.


More information about the Digitalmars-d mailing list