== Quote from lws ([email protected])'s article > On 2009-12-14 07:01:47 -0800, dsimcha <[email protected]> said: > > == Quote from lws ([email protected])'s article > >> I don't know if I believe this is necesarrily bad. It's revealing some > >> bad coding on your part. > >> You shouldn't be doing opEquals with an rvalue of a class. Make > >> getFoo return a reference. > >> ref Foo getFoo() {} fixes the problem and avoids value-copying for no > >> reason to an rvalue that's going to get garbage collected. > > > > 1. This was in DFL's code, not stuff I wrote. > > 2. It was a small struct that was cheap to copy, not a class. > > 3. At any rate, the inconsistency with builtins is inexcusable. > 1. Well, stuff like this is good warning to whomever about the code. > Since D is a imperative language, it should at least give you a warning > when you're doing something really inefficient that has a boilerplate > way of accomplishing it that is much faster.
Right, but only if this warning doesn't have too many false positives that are just annoying when the programmer **does** know what he/she is doing. In this case, passing small structs by value isn't inefficient. > 2. That's odd. structs DO have stack scope in D. Right? It > shouldn't even warn in that case. IMHO. That's my whole point. The behavior is a bug, not a feature. > 3. For classes, it is consistent with the whole point of the new const > stuff and the GC, and the fact that they are heap objects by > definition. Classes have always been treated "differently." And I > think it's good. Walter has enabled a lot of expressiveness with the > syntax in D when compared to C++, and it allows nice warnings when > you're doing things you probably shouldn't. > Unfortunately, this isn't an error.... Maybe for some reason you > REALLY want to be copying around structs and classes. Maybe what we need is for it to be legal to pass rvalues to functions that expect const ref params. If it's an rvalue, just place it on the caller's stack frame implicitly and be done with it.
