On Mon, 02 Mar 2015 00:15:02 +1100, Daniel Murphy wrote:

> "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.

so i should buy a reddit account with good reputation to change that, as we all know that only reddit users matters.

On Sunday, 1 March 2015 at 08:57:17 UTC, Matthias Bentrup wrote:
> 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);
> }

Well don't do that... :-)

Looks like a fly in the ointment. The most straightforward solution is to always add the opAdd/Release cycle when passing globals to impures. That's probably good enough. You probably don't pass a global to an impure very often anyway.

On Sunday, 1 March 2015 at 07:04:09 UTC, Zach the Mystic wrote:
> 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.

One more tidbit:

class RcType {
  RcType r;
  ...
}

void fun(RcType x, RcType y);

auto z = new RcType;
z.r = new RcType;

fun(z, z.r);

From within fun(), z can alias z.r, but z.r can't possibly alias z. Thus, only z.r needs to be preserved. The algorithm should go "For each parameter, add one ref/release cycle for every other parameter which could possibly generate an alias to it".

We're approaching optimal here. This is feeling good to me.

On 2015-03-01 14:15, Daniel Murphy wrote:

> 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.

I don't agree. If those are the final names, no. But I do have method names like "retain" and "release".

I don't really like how it's done with ranges either.

-- 
/Jacob Carlborg

On 1 March 2015 at 18:57, Matthias Bentrup via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
> 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);
> }

Thing here is that 'a' does not belong to main().
There must be a reference on the caller's stack for it to be passed to
a non-pure function.
If a function X passes a value it does not own to some other function,
then X needs to increment the refcount such that it holds one
reference for itself.
For the callee, it received via an argument, so it has confidence a
stack reference exists, and it doesn't need to bump anymore down the
call tree.