Thread overview | |||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
February 28, 2015 DIP74 updated with new protocol for function calls | ||||
---|---|---|---|---|
| ||||
Defines a significantly better function call protocol: http://wiki.dlang.org/DIP74 Andrei |
March 01, 2015 Re: DIP74 updated with new protocol for function calls | ||||
---|---|---|---|---|
| ||||
Posted in reply to Andrei Alexandrescu | 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??
|
March 01, 2015 Re: DIP74 updated with new protocol for function calls | ||||
---|---|---|---|---|
| ||||
Posted in reply to Zach the Mystic | 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
|
March 01, 2015 Re: DIP74 updated with new protocol for function calls | ||||
---|---|---|---|---|
| ||||
Posted in reply to Zach the Mystic | 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);
}
|
March 01, 2015 Re: DIP74 updated with new protocol for function calls | ||||
---|---|---|---|---|
| ||||
Posted in reply to Andrei Alexandrescu | 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
|
March 01, 2015 Re: DIP74 updated with new protocol for function calls | ||||
---|---|---|---|---|
| ||||
Posted in reply to Paulo Pinto | 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
|
March 01, 2015 Re: DIP74 updated with new protocol for function calls | ||||
---|---|---|---|---|
| ||||
Posted in reply to Andrei Alexandrescu | 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 |
March 01, 2015 Re: DIP74 updated with new protocol for function calls | ||||
---|---|---|---|---|
| ||||
Posted in reply to Paulo Pinto | 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 |
March 01, 2015 Re: DIP74 updated with new protocol for function calls | ||||
---|---|---|---|---|
| ||||
Posted in reply to Andrei Alexandrescu | 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 |
March 01, 2015 Re: DIP74 updated with new protocol for function calls | ||||
---|---|---|---|---|
| ||||
Posted in reply to 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. |
Copyright © 1999-2021 by the D Language Foundation