GC vs Resource management.

[Rikki Cattermole via Digitalmars-d]

On Saturday, 3 May 2014 at 12:28:03 UTC, monnoroch wrote:
> I've been reading all the topics with those "radical" ideas 
> about the GC and dtors and, honestly, i'd rather call them 
> "insane". After all the reading and thinking, i came to 
> conclusion, that what Andrey suggests is to call dtors only on 
> stack-allocated structs. That also implies, that one can't put 
> those in containers and gc-allocated objects.
> Since all of them: containers, structs, classes -- are all 
> first-class objects they must be all nicely combined in code, 
> without any unintuitive stuff.
> I mean, really, let us look at c++ strings. There are const 
> char*, std::sting, QString, Poco::String, icu::UnicodeString, 
> and every big project uses it's own strings implementation that 
> can't be used together in a sane way. That is what great in D: 
> you just threw the idea of library-implemented strings away and 
> made it not only "standard", but special and that what makes it 
> intuitive and simple (unless you interact with c++). Never seen 
> any non-standart strings for D.
> The point is, that every library and every coder add to the 
> project incompatible and difficult to use together stuff, so 
> every programmer already has to think of all the problems with 
> other's people code, and you just can't add same shit to the 
> language. All elements must nicely interact together and 
> otherwise it's a total disaster.
> Back to the dtors: i understand, that all the stuff you propose 
> could make GC faster, simpler, and cooler, but it sounds insane 
> to anyone, who uses the language, not develops it, that if you 
> create struct object, dror will be called, but if you place the 
> copy in a container, it wont. It's just unanderstandable from 
> user's point of view.
+1 about dtors.

> Now, for the solution.
>
> First, we can just fix this shit with arrays of structs and 
> that's it. That still lives us with false pointers problem: not 
> everything gets collected. That's no good. So, i propose to 
> think of actually separating gc-memory management (via GC) and 
> other resources management: via some new (or maybe old) 
> mechanism.
>
> Let me start with listing of existing solutions:
>
> 1) C.
> That is the simplest way: fully-manual resource management.
> It's obvious, we can't do that in D, because it's supposed to 
> be simpler for coding, than C.
>
> 2) Go.
> Actually, this one is not that different: it uses GC for memory 
> only, and manual management for all the rest (with help of 
> defer operator). We can't do it either, for the same reasons.
>
> 3) C++.
> This one is semi-automatic (talking about user code, not some 
> allocator libraries): you choose the scheme (refcounting, 
> unique reference) and then it'll do the rest.
>
> 4) Rust.
> I'm not a pro here, but as i understand, it uses C++ way, and 
> adds gc-collected pointers, but not sure, so help me here.
>
> 5) Python.
> GC-only, except one clever case: with statement calls close() 
> method.
>
>
> Please, if there are any pros in other platforms, add your 
> knowledge to this list, i would very much love to learn (same, 
> if a made any mistakes).
>
>
> Now, for D: obviously D has GC-managed heap. First, we should, 
> like in Go, leave only managing gc-memory to the GC -- this is 
> just rephrasing Andreys proposal.
> The simplest way o manage all other resources would be manual, 
> Go-way:
>
> A a = A();
> scope(exit)
>     a.~A();
>
> But it's to annoying, to that all the time, so we really want 
> dtors to save us lost of typing and debugging, but they can't 
> be called all the time, because we can put stuff in 
> GC-collected objects.
>
> What i propose, is to include new concept in D: scoped objects.
> Any object (no matter is it a class or struct instance) can be 
> either scoped or not.
> Dtors for scoped objects are called when out of scope, dtors 
> for non-scoped objects are not called at all.
>
> It is actually as simple as rewrite code
>
> A a = A();
>
> as
>
> A a = A();
> scope(exit)
>     a.~A();
>
> For all a's, which are scoped objects.
>
> For me, it is both a simple concept and good rationalization 
> for difficult dror-gets-called-or-not rules.
>
> That leaves only to determine, what objects are scoped. Well, 
> that is obviously stack-allocated structs, gc-allocated scope 
> classes and gc-allocated structs in scope classes.
>
> But that is just my idea. This post has so many words, because 
> it's very important, that D devs make good decision on that 
> deep problem, and the key to such decision is information and 
> discussion.
>
> UPD:
> Also, about arrays and slices: if we could easily pass them 
> around as cost ref-s, just like in C++, then we could make them 
> value-types and they wouldn't require any ref counting. I would 
> suggest, make all "in" function arguments const refs.

I like the idea of scoping dtor's. But I still want the ability 
to say:
Hey I have this global variable, if I assign a value to it and 
later null it, it'll call its destructor if its not referenced 
anywhere else.
Which in turn would make me think ref counting would be a good 
idea.

But either way, I think we are getting ahead of ourselves with 
all these 'major' proposed changes. I think its time to step back 
and say hey D2 shouldn't be changed much more lets freeze it.
Now lets plan for D3.
Breakage between D2 and D3 is acceptable but not in D2 to the 
extent some of these proposals is bringing to the table.