Yigal Chripun wrote:
> On 19/04/2009 22:52, Andrei Alexandrescu wrote:
>> Jarrett Billingsley wrote:
>>> On Sun, Apr 19, 2009 at 8:41 AM, Denis Koroskin <2korden@gmail.com> wrote:
>>>> What's a rationale behind an issue described bug 2621? http://d.puremagic.com/issues/show_bug.cgi?id=2621
>>>>
>>>> Why isn't it allowed anymore?
>>>>
>>>> It broke quite a lot of my code. And while it is fixable by doing
>>>>
>>>> auto tmp = someFunctionThatRetunsStruct();
>>>> someMethodThatAcceptsStructByReference(tmp);
>>>>
>>>> it looks ugly and unnecessary.
>>>
>>> I just thought of something. Why the hell should we keep C++'s "const ref" anyway? When you use "const ref" it means you want it to be read-only and fast to pass large structures. But why should the onus of passing value types byref be on the programmer? Why not make it so "const valuetype" will pass byval for smaller values and byref for larger, completely freeing the programmer from this tedious crap? It's not something that I care about, and the threshold of byval vs. byref differs from platform to platform.
>>>
>>> Let's nip this in the bud right now. A const value type parameter should automatically decide whether to pass by reference or not.
>>
>> I suggested that change. First let me clarify that the suggestion above cannot work. Due to aliasing, leaving it to the compiler to choose between by-value and by-reference leads to functions breaking when the size of the object changes, which is unacceptable.
>>
>> struct S { int x; ... }
>> void foo(const S s1, ref S s2)
>> {
>> s1.x = 5;
>> s2.x = 6;
>> }
>>
>> S s;
>> foo(s, s); // messed up
>>
>> Now onto why ref was disallowed to bind to an rvalue. This is because some functions take things by ref intending to change them. Passing an rvalue is in such cases a bug.
>>
>> I agree there are functions that only want to use ref for speed purposes. I suggested Walter to use ref? for those. ref? means it could be an rvalue or an lvalue.
>>
>>
>> Andrei
> 
> that does not compile.
> you tried to change a *const* struct...
> 
	Change it to:
int foo (const S s1, ref S s2)
{
   s2.x = 6;
   return s1.x;
}

S s;
s.x = 3;
x = foo (s, s); // messed up

		Jerome
- --
mailto:jeberger@free.fr
http://jeberger.free.fr
Jabber: jeberger@jabber.fr

On 2009-04-19 15:52:02 -0400, Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org> said:

> Now onto why ref was disallowed to bind to an rvalue. This is because some functions take things by ref intending to change them.

True.


> Passing an rvalue is in such cases a bug.

I disagree. Function modify the temporary value, then the value is forgotten. It's just like calling a function and ignoring the returned value. It could be a bug, but it may not.

For instance, a function may just be performing some destructive operation on the argument, in which case a temporary rvalue may very-well be appropriate since you are unlikely to need the result afterwards.

Even C++0x saw the need and added rvalue non-const reference.
<http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2004/n1690.html>


-- 
Michel Fortin
michel.fortin@michelf.com
http://michelf.com/

On Sun, 19 Apr 2009 23:52:02 +0400, Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org> wrote:

> Now onto why ref was disallowed to bind to an rvalue. This is because some functions take things by ref intending to change them. Passing an rvalue is in such cases a bug.
>
> I agree there are functions that only want to use ref for speed purposes. I suggested Walter to use ref? for those. ref? means it could be an rvalue or an lvalue.
>
>
> Andrei

I don't understand why it is a bug, could you please elaborate on it?

But anyway, why disallow pass-by-const-ref? It won't be modified anyway!

struct Rect
{
   int x, y, w, h;
}

Rect get()
{
   Rect r;
   return r;
}

void pass(ref const(Rect) rect)
{
}

void main()
{
   pass(get());
}

Error: function test.pass (ref const(Rect) rect) does not match parameter types (Rect)
Error: get() is not an lvalue

Also note that if you are right, and modifying a temporary is a bug, then C++ is in a winning position here, because its const system is tail-const, and that's exactly what is required here - you can't modify a variable, but you can mofify whatever it points to.

We could have this behavior, too, by passing final-ref, not const-ref. Final qualifier means that an object it is applied to won't be modified, but it makes no statements about transitivity. Essentially, that's what C++ const does.

Here is an example:

struct RefCounted(T)
{
   T* obj; // includes "int numReferences;" intrusively.
}

void passObject(ref final(RefCounted!(Foo)) foo)
{
   auto copy = foo; // increments reference counter. Note that this don't modify the foo itself, only object which is available through it.
}

// passObject(new Foo()); // doesn't work, can we do anything with it? I'd like to hear your ideas.
passObject(RefCounted!(new Foo())); // allowed!