D 2015/2016 Vision?

[bitwise via Digitalmars-d]

On Monday, 5 October 2015 at 17:27:30 UTC, Jonathan M Davis wrote:
> On Sunday, 4 October 2015 at 18:02:21 UTC, bitwise wrote:
>> There are several things in phobos that are classes. This goes 
>> against the nogc goal, so what's the plan?
>
> Now, Walter and Andrei have talked about adding some sort of 
> reference counting to the language so that we can support a 
> class hierarchy that's specifically reference-counted 
> (exceptions in particular would be a target for that) - though 
> that doesn't necessarily mean that they won't use the GC, just 
> that their destruction will be deterministic. And std.allocator 
> should make it easier to use classes without the GC. So, the 
> situation with classes and the GC will be improving.

> - Jonathan M Davis

The deterministic destruction is actually what I'm after.

A ubiquitous use case in graphics apps:

class Texture { }
class Texture2D : Texture
{
     this() { /* load texture... */ }
     ~this { /* free texture */ }     // OOPS, when, if ever, will 
this be called?
}

I think there is some kind of RC(T) coming down the pipe, but I 
would prefer a natural solution like the one provided by DIP74. 
No awkward syntax, no type obfuscation.

As you said, I believe the GC performance issues can be mitigated 
well enough using allocators and such, so I'm not that concerned 
about it.

One thing not mentioned on DIP74 is @nogc. I wouldn't want my RC 
class to end up nested in a regular GC class, but it appears that 
DIP74 still GC allocates the RC class. So will RC classes, based 
on this DIP, be allowed in a @nogc context?

I think the solution to the above question is as simple as 
allowing RC classes to have something like "static T opNew(){}".

      Bit