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
