RAII, value classes and implicit conversion

[Boris Kolar]

== Quote from Chris Nicholson-Sauls (ibisbasenji at gmail.com)'s article
> > 2. Garbage collection must be avoided:
> >
> >   const class Scoped(T): T, Local {
> >     this(T object) {
> >       _object = object;
> >     }
> >     this.T {
> >       return _object;
> >     }
> >     private T _object;
> >   }
> >   Scoped(T) scoped(T)(T object) {
> >     return new Scoped!(T)(object);
> >   }
> >   class Foo {
> >     void foo() { ... }
> >   }
> >   void test() {
> >     Foo foo = scoped(new Foo());
> >     foo.foo();
> >     // foo is deleted here :)
> >   }
> >   void test2() {
> >     scoped(new Foo()).foo();
> >     // Foo instance is deleted here too! :D
> >   }
> I'm not so sure I understand how this is "avoiding" GC... it seems to be
/enforcing/ it.
> But its still a fascinating design concept.

Sorry, I expressed my "avoiding GC" idea very unclearly. What I meant was avoiding
long GC runs, which occour when the system runs out of memory and a whole bunch of
objects is checked for garbage. There are no guarantees about how long such a GC run
may take. That's why real-time programs must avoid situations when system must GC
unused objects. And by "real-time programs" I don't mean just mission-critical
software that lives depend on, but also games and multimedia applications.

> If I want value semantics, I'll generally use a struct.  Just can't think of
cases right
> off hand where I'd want this.

Perhaps when you would need a "struct" to override some method. I'd like to see that
the only difference between structs and classes is that structs don't have VMT table
(and thereforce can't override methods). So, structs are in a sense 'lightweight'
classes.

> Also, it makes me think of C# style properties -- and while I would like to see
them in D,
> I don't need constant false hope.  ;)

I like D-style properties much better :)

> > Also, get rid of static opCall
> Just: no.  Leave it be.

Well, I meant replace it with constructor (for structs). Or it can stay, but no
struct can define both constructor and opCall.