[Dlang-study] [lifetime] Few root decisions to take on RC classes

[Martin Nowak]

On 11/03/2015 01:36 AM, Andrei Alexandrescu wrote:
> Probably that's the general case. But if a class has no public data
> members and member functions that don't leak member addresses, it stands
> to reason conversion could break no code.

If it's a non-final class (always a bad idea for an API but we have
plenty in druntime/phobos), it could cause troubles in derived classes.
But you're right if it doesn't escape anything conversion should be
fairly smooth.

>> Same goes for specifying an allocator to use with a ref counted class.
> 
> I don't understand this part, could you please detail.

Guess this is very uncontroversial.

Timon asked on the other thread how to specify an allocator for a class.
http://forum.dlang.org/post/laudxyyjjvkivqsupczq@forum.dlang.org

Something like operator new/delete that hardcodes the allocator used for
a class is a bad idea, b/c you don't know all usage patterns for a class
in advance. Also not all allocators have a single global instance.
So this should be decided at runtime by the user of a class.

>> It seems like a much better idea to decide that when using the class as
>> opposed to when implementing the class.
> 
> Such an approach would need to first define which subset of classes work
> with both GC and RC. Do we agree on that? For example, classes that
> escape addresses of data members work safely only with GC. Same goes
> about classes that escape "this".
> 
> For my money, I have long looked for a way to implement reference
> counting outside of the class definition. I had my mind modeled after
> the C++ approach, and it does seem like a very sensible idea. Lately,
> however, I got disabused about the notion because I figured the set of
> manipulations allowed to GC classes largely surpasses the set of
> manipulations allowed to RC classes.
> 
> I am curious how you think you can define these two subsets.

First it seems that the RC set is a strict subset of the GC one, so any
RC class could also be used as GC class.

The operations not allowed on an RC class are calling a method that
escapes a reference to the class or one of it's fields, and escaping a
reference to one of it's public fields.

Most of this could be achieved with a wrapper similar to Proxy, if there
was an inferred @noescape attribute for methods.


And yes, this means you'd have to rewrite code that implicitly shares
ownership

class Widget
{
  static Widget[] all;
  this()
  {
    all ~= this;
  }
}

to something that's explicit about how the ownership is shared (in this
case by using RC).

class Widget
{
 static RC!Widget[] all;
@noescape:
  this() {}
}

RC!Widget widget()
{
  auto rc = RC!Widget();
  Widget.all ~= rc;
  return rc;
}


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://lists.puremagic.com/pipermail/dlang-study/attachments/20151106/526e5356/attachment.sig>