Defines a significantly better function call protocol:

http://wiki.dlang.org/DIP74

Andrei

On Saturday, 28 February 2015 at 21:12:54 UTC, Andrei Alexandrescu wrote:
> Defines a significantly better function call protocol:
>
> http://wiki.dlang.org/DIP74
>
> Andrei

This is obviously much better, Andrei.

I think an alternative solution (I know -- another idea -- against my own first idea!) is to keep track of this from the caller's side. The compiler, in this case, when copying a ref-counted type (or derivative) into a parameter, would actually check to see if it's splitting the variable in two. Look at this:

class RcType {...}

void fun(RcType1 c, RcType1 d);

auto x = new RcType;

fun(x, x);

If the compiler were smart, it would realize that by splitting parameters this way, it's actually adding an additional reference to x. The function should get one x for free, and then force an opAdd/opRelease, for every additional x (or x derivative) it detects in the same call.

This might be even better than the improved current proposal. The real key is realizing that duplicating an lvalue into the same function call is subtly adding a new reference to it.

Eh??

On 2/28/15 11:04 PM, Zach the Mystic wrote:
> keep track of this from the caller's side.

Thanks, I'll keep that in mind. -- Andrei

On Sunday, 1 March 2015 at 07:04:09 UTC, Zach the Mystic wrote:
> On Saturday, 28 February 2015 at 21:12:54 UTC, Andrei Alexandrescu wrote:
>> Defines a significantly better function call protocol:
>>
>> http://wiki.dlang.org/DIP74
>>
>> Andrei
>
> This is obviously much better, Andrei.
>
> I think an alternative solution (I know -- another idea -- against my own first idea!) is to keep track of this from the caller's side. The compiler, in this case, when copying a ref-counted type (or derivative) into a parameter, would actually check to see if it's splitting the variable in two. Look at this:
>
> class RcType {...}
>
> void fun(RcType1 c, RcType1 d);
>
> auto x = new RcType;
>
> fun(x, x);
>
> If the compiler were smart, it would realize that by splitting parameters this way, it's actually adding an additional reference to x. The function should get one x for free, and then force an opAdd/opRelease, for every additional x (or x derivative) it detects in the same call.
>
> This might be even better than the improved current proposal. The real key is realizing that duplicating an lvalue into the same function call is subtly adding a new reference to it.
>
> Eh??

Note that you can get the same issue without duplicate parameters, if you pass an alias to a global variable.


static A a;

void fun(A x) {
  a = null; // Releases x
  x.func();
}

void main() {
  a = new A();
  fun(a);
}

On Saturday, 28 February 2015 at 21:12:54 UTC, Andrei Alexandrescu wrote:
> Defines a significantly better function call protocol:
>
> http://wiki.dlang.org/DIP74
>
> Andrei

What about having an UDA or a mixin for marking the types as RCO?

--
Paulo

On 3/1/15 1:41 AM, Paulo Pinto wrote:
> On Saturday, 28 February 2015 at 21:12:54 UTC, Andrei Alexandrescu wrote:
>> Defines a significantly better function call protocol:
>>
>> http://wiki.dlang.org/DIP74
>>
>> Andrei
>
> What about having an UDA or a mixin for marking the types as RCO?

We prefer opAddRef/opRelease to define an RCO, same as empty/front/popFront define a range. -- Andrei

On 2015-02-28 22:12, Andrei Alexandrescu wrote:
> Defines a significantly better function call protocol:
>
> http://wiki.dlang.org/DIP74

Is there any checking that the signatures of these methods matches the ones in the base class if an implicit conversion to the base class is made? Example:

class Base
{
    void opAddRef();
    void opRelease();
}

class Sub : Base
{
    int opAddRef();
    int opRelease();
}

Base b = new Sub; // what happens here?

On all examples showing how the compiler will insert calls to "opAddRef" and "opRelease" the return value is ignored. Is there a point in returning anything form these methods?

-- 
/Jacob Carlborg

On 2015-03-01 10:41, Paulo Pinto wrote:

> What about having an UDA or a mixin for marking the types as RCO?

I already commented on that. Andrei said [1] he was fine with breaking code for this feature. I don't understand why because it so easy to fix with a compiler recognized UDA [2].

[1] http://forum.dlang.org/post/mcqik9$5fu$1@digitalmars.com
[2] http://forum.dlang.org/post/mcp5nu$1nus$1@digitalmars.com

-- 
/Jacob Carlborg

On 2015-03-01 13:41, Andrei Alexandrescu wrote:

> We prefer opAddRef/opRelease to define an RCO, same as
> empty/front/popFront define a range. -- Andrei

I don't see how a UDA would hurt.

-- 
/Jacob Carlborg

"Jacob Carlborg"  wrote in message news:mcv342$2c9t$1@digitalmars.com...

> I already commented on that. Andrei said [1] he was fine with breaking code for this feature. I don't understand why because it so easy to fix with a compiler recognized UDA [2].

Because a compiler recognized UDA is an additional complication for something that is unlikely to be a problem for anyone.  Do you have code with methods named opAddRef?  No?  Me neither.