On 28 October 2015 at 21:29, David Nadlinger via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
> On Wednesday, 28 October 2015 at 11:21:17 UTC, Manu wrote:
>>
>> RC is okay-ish in C++11 (with rval references), although it could be much better, for instance, the type mangling/wrapping induced by this sort of library solution always leads to awkward situations, ie, 'this' pointer in a method is not an RC object anymore! Methods can't give out pointers to themselves (ie, signaling events where it's conventional to pass a 'sender' to the subscribers). Pretty massive fail!
>
>
> Did you look into doing something like std::enable_shared_from_this? I use it pretty routinely in networking code (boost.asio), and while it is not as pretty as it could be, it does the trick.

I did. We ended up with custom solutions, tailored to take advantage
of our specific and fairly unconventional environment. Our RC is
invasive in most cases, using a duck-typed approach to the general
API.
I'm not really proud that we re-invented that wheel (among many,
because C++ offerings are generally insufficient), but it had to be
done.

On 10/28/2015 04:13 AM, Jacob Carlborg wrote:
> On 2015-10-27 22:19, Andrei Alexandrescu wrote:
>
>> That doesn't seem to be the case at all. -- Andrei
>
> I'm not a C++ or Rust expert. But I think that in Rust and with the new
> C++ guide lines the idea is to use reference counting pointers only for
> owning resources. If you want to pass the data to some of part of the
> code, that does not need to own the resource, a raw pointer should be used.

Problem with that is in C++ it's just unsafe and in Rust it's requires too much work from the programmer. We don't think either style is best for D. -- Andrei

On 2015-10-28 09:50, Paulo Pinto wrote:

> Hence why I mentioned they are more RC friendly.
>
> Swift, because it doesn't have them.
>
> Objective-C, because termination is the only option so no need to worry
> about preserving counters.
>
> I was typing on the phone, so didn't want to provide the full explanation.

Fair enough :)

-- 
/Jacob Carlborg

On 10/28/2015 7:58 AM, Andrei Alexandrescu wrote:
> On 10/28/2015 04:13 AM, Jacob Carlborg wrote:
>> On 2015-10-27 22:19, Andrei Alexandrescu wrote:
>>
>>> That doesn't seem to be the case at all. -- Andrei
>>
>> I'm not a C++ or Rust expert. But I think that in Rust and with the new
>> C++ guide lines the idea is to use reference counting pointers only for
>> owning resources. If you want to pass the data to some of part of the
>> code, that does not need to own the resource, a raw pointer should be used.
>
> Problem with that is in C++ it's just unsafe and in Rust it's requires too much
> work from the programmer. We don't think either style is best for D. -- Andrei
>
>

Let's continue this in the mailing list.

On Tuesday, 27 October 2015 at 18:10:18 UTC, deadalnix wrote:
> I've made the claim that we should implement reference counting as a library many time, so I think I should explicit my position. Indeed, RC require some level a compiler support to be safe. That being said, the support does not need to be specific to RC. On fact, my position is that the language should provide some basic mechanism on top of which safe RC can be implemented, as a library.
>
> The problem at hand here is escape analysis. The compiler must be able to ensure that a reference doesn't escape the RC mechanism in an uncontrolled manner. I'd like to add such mechanism to the language rather than bake in reference counting, as it can be used to solve other problem we are facing today (@nogc exception for instance).

Here's a link to the reference safety system I proposed some months ago:

http://forum.dlang.org/post/offurllmuxjewizxedab@forum.dlang.org

I'm very far from having the expertise needed to know whether it would be worth its weight in practice, but it was better to write it out than to keep it bottled up in my head. I hope it will be of some use.

On Thursday, 29 October 2015 at 20:31:49 UTC, Zach the Mystic wrote:
> On Tuesday, 27 October 2015 at 18:10:18 UTC, deadalnix wrote:
>> I've made the claim that we should implement reference counting as a library many time, so I think I should explicit my position. Indeed, RC require some level a compiler support to be safe. That being said, the support does not need to be specific to RC. On fact, my position is that the language should provide some basic mechanism on top of which safe RC can be implemented, as a library.
>>
>> The problem at hand here is escape analysis. The compiler must be able to ensure that a reference doesn't escape the RC mechanism in an uncontrolled manner. I'd like to add such mechanism to the language rather than bake in reference counting, as it can be used to solve other problem we are facing today (@nogc exception for instance).
>
> Here's a link to the reference safety system I proposed some months ago:
>
> http://forum.dlang.org/post/offurllmuxjewizxedab@forum.dlang.org
>
> I'm very far from having the expertise needed to know whether it would be worth its weight in practice, but it was better to write it out than to keep it bottled up in my head. I hope it will be of some use.


1) Assignment to RCObject
-------------------------


{
	RCObject obj = new RCObject()
	Item item1 = obj.items[x];
	
	_temp1 = obj;
	obj = new RCObject();


	_temp2 = obj;
	obj = new RCObject();
}



2) Entering a subscope
----------------------

With this I mean entering a subscope that assigns to the RCObject.


{
	RCObject obj2 = new RCObject()
	RCObject obj = new RCObject()
	

	_temp1 = obj;				//(2) Entering a subscope
	{
		_temp2 = obj;			//(1) Assignment to RCObject
		obj = new RCObject();
	}
}


3) Leaving a scope.
-------------------

The Item is not reference counted.

{
	Item item1;
	{
		RCObject obj = new RCObject();
		//item1 = obj.items[x];		//(3) Leaving subscope
	}
}



{
	RCObject obj = new RCObject();
	Item item1;
	
	_temp1 = obj;				//(2) Entering subscope
	{
		_temp2 = obj;			//(1) Assignement to RCObject
		obj = new RCObject();
		//item1 = obj.items[x];		//(3) Leaving subscope

		_temp3 = obj;			//(1) Assignement to RCObject
		obj = new RCObject();
	}
}




4) RCObject joins a scope
-------------------------


{
	_temp1 = obj.field.rcobject;		//(4) RCObject joins current scope.
	Item item1 = obj.field.rcobject.a.items[0];


	//_temp1;				//(2) Entering subscope
	{
		_temp3 = obj.field.rcobject;	//(1) Assignment to RCObject
		obj.field.rcobject = new RCObject();
	}

	_temp4 = obj.field.rcobject;		//(4) RCObject joins current scope.
	item1 = obj.field.rcobject.a.items[2];
}

On 10/27/2015 12:41 PM, Andrei Alexandrescu wrote:
> It follows that if we want safe reference counting, there must be language support for it. One possibility is to attach an attribute to the class definition:
> 
> @safe @rc class Widget {
>   ...
> }

Let's think about this more clearly before we bake a monolithic feature for a single problem into the language.

A few thoughts:

- @rc and @noescape are orthogonal

  while @rc requires @noescape the latter could
  be useful for other purposes

- If the compiler knows a reference has a limited lifetime
  it could check for @noescape making most of RC implementable
  in a library.

  struct RC
  {
    Object get() return; // lifetime of Object is bound to RC, compiler
could check any function called on Object for @noescape
  }

- I'm not a fan of adding yet another attribute but as inference support
  is currently limited it seems we'd need an explicit attribute for
  public APIs.

On 10/27/2015 01:27 PM, Andrei Alexandrescu wrote:
> Unrelated, and a foreshadowing of the discussion on the lifetime mailing list: the compiler has ample opportunity to fuse incs/decs together, so the signatures of these functions is:
> 
> void opInc(uint delta);
> void opDec(uint delta);

Any hint/numbers showing that this is actually useful?
Implementing such a cross statement optimization is quite some work. If
this occurs often enough (in particular for shared classes with atomic
ref counting) it might be worth the effort.

On 11/01/2015 09:51 PM, Martin Nowak wrote:
> Any hint/numbers showing that this is actually useful?

Also doesn't a good backend optimizer already fuse writes?

On Sunday, 1 November 2015 at 20:55:00 UTC, Martin Nowak wrote:
> On 11/01/2015 09:51 PM, Martin Nowak wrote:
>> Any hint/numbers showing that this is actually useful?
>
> Also doesn't a good backend optimizer already fuse writes?

AFAIK the fear of RC being too slow comes from C++'s shared_ptr's reference count being required to be synchronized by the C++ spec, which heavily limits what kinds of optimizations that can be done on it. Thread-local by default RC should, in theory, be able to be optimized much much more aggressively.