D 2015/2016 Vision?

[bitwise via Digitalmars-d]

On Tuesday, 6 October 2015 at 17:20:39 UTC, Jonathan M Davis 
wrote:
> On Tuesday, 6 October 2015 at 17:03:07 UTC, bitwise wrote:
>> On Tuesday, 6 October 2015 at 06:45:47 UTC, Jonathan M Davis 
>> wrote:
>>> They're not the same thing at all. scoped is supposed to put 
>>> the class on the stack, not the heap. And it's not 
>>> ref-counted. It's so that you can create a class object in 
>>> place, use it, and throw it away without doing any heap 
>>> allocation. Essentially, it allows you to use a class as if 
>>> it were a non-copyable struct. Even if we end up with 
>>> ref-counting supported in the language, it doesn't obviate 
>>> the need for scoped classes. They're for different use cases.
>
>> For my purposes, they are pretty much the same.
>>
>> So again, I'll paste the same example:
>>
>> class Texture { }
>> class Texture2D : Texture {
>>     this() { /* load texture... */ }
>>     ~this { /* free texture */ }     // OOPS, when, if ever, 
>> will this be called?
>> }
>>
>> Memory is not only thing that has to be cleaned up.
>
> Well, they might seem the same when you only look at that part, 
> but they won't both solve your problem, depending on what 
> you're trying to do.
>
> But in general, at this point, with D, if you want 
> deterministic destruction, then you use structs. Classes are 
> not the appropriate place for it. If they were ref-counted, 
> then they could be, but as long as they're not, then classes 
> are not the place to have stuff that cares about deterministic 
> destruction. And if you're stuck with stuff in classes that do 
> care about deterministic destruction, then you have to use the 
> sort of solutions that C# and Java use where you don't rely on 
> the destructor/finalizer to clean anything up except for the 
> cases where you screw up and forget to manually call the 
> function that does the cleanup.

I'm not sure what else I can say. The example I posted says it 
all, and it can't be done properly in D (or C#, but why lower the 
bar because of their mistakes? ;)

I'm not sure exactly how C# and Java handle destruction for 
non-memory resources, but I'm guessing it's something like 
calling GC.collect() manually every couple of seconds. If the 
textures aren't released in the destructor, I don't really see 
any other way to tell when they're referenced or not.

Of course though, mobile devices are the new PC, and battery life 
is very much a concern, so this is a total waste...especially if 
I'm doing very little GC allocation anyways. Also, of course, 
there are the performance issues.

> I expect that we'll get ref-counting for classes at some point, 
> since while ref-counting with structs works, as I understand 
> it, it does have some holes that make it less than ideal (but 
> not necessarily unusable). And for some reason, IIRC, 
> RefCounted doesn't work with classes, so you'd be forced to 
> write your own ref-counted wrapper. It can certainly be done 
> though.
>
> - Jonathan M Davis

Correct, RefCounted doesn't work with classes. Not sure why, but 
I wrote my own, and trivial unittests pass:
http://dpaste.dzfl.pl/997615d2d188

But again, as I've already mentioned, it hides the type, has 
annoying syntax, and most importantly, is error prone. I can't 
really write a class thats meant to be used with RC(T) and know 
that no one will ever try to use it on it's own, GC allocated.

D needs a real solution here.
http://imgur.com/v6CIWln

     Bit