On 23 March 2018 at 16:46, Jonathan M Davis via Digitalmars-d <digitalmars-d@puremagic.com> wrote: > On Friday, March 23, 2018 22:44:35 Nick Sabalausky via Digitalmars-d wrote: >> It never made any sense to me that there could be any problem >> with the compiler automatically creating a temporary hidden >> lvalue so a ref could be taken. If there IS any problem, I can >> only imagine it would be symptomatic of a different, larger >> problem. > > It can be a serious API problem if you can't look at ref and know that the > intention is that the original argument's value will be used and then > mutated (whereas with out, it will be mutated, but the original value won't > be used).
Okay, let's read 'const ref' every time I say 'ref'. I thought that would be fairly safe to assume. Sorry! > However, that could be solved by having a different attribute indicate that > the idea is that the compiler will accept rvalues and create temporaries for > them if they're passed instead of an lvalue. Then, the situation is clear. No, no attributes.. Just accept any argument to const-ref! The function's not gonna change it. > As for rvalue references in general, I can never remember what exactly the > problem is. IIRC, part of it relates to the fact that it makes it impossible > for the compiler to know whether it's dealing with an actual lvalue or not, > which has serious @safety implications, and in the case of C++, complicates > things considerably. Andrei has plenty of nasty things to say about how > rvalue references in C++ were a huge mistake. It's just that I can never > remember the arguments very well. > > The use of scope with DIP 1000 may reduce the problem such that scope ref > could be made to work @safely (I don't know) True, but if you follow that line of reasoning, then this case must equally be banned: T temp = f(); func(temp); The @safety fear is that the pointer to the stack arg may escape, and that's identical whether the argument is an explicit temp, or an implicit one. > but that by itself isn't > enough if you want it to be clear whether a function is supposed to be > mutating the argument Functions that receive const args make it pretty clear that they don't intend to mutate the arg. > I get the impression that this issue is one where it seems like a small one > on the surface but that when you get into the guts of what it actually means > to implement it, it gets nasty. It really doesn't... the compiler just make the same temp that I type with my hands. That's literally all that it needs to do. I'd bet money it's a one-paragraph change. > Clearly, it's a PR issue in Manu's world, but it may also be a performance > problem. I > don't know. Either way, it's clear that Manu and others like him think that > the fact that D doesn't have rvalue references is a serious deficiency. That's an understatement, but yes :P We want to call C++ code. The D code shouldn't be objectively worse than the C++ code we're trying to escape, otherwise we're undermining our gravity towards D. We can't have a situation that goes "I wrote this 3 line function in D, but now it's 6 lines because I had to break args to temps, it's objectively worse than the equivalent C++ function... why am I writing it in D again?".