Two features will make this already great language even better:

1. Explicit interface implementation
  interface IFoo {
    void bar();
  }
  class Foo: IFoo {
    ...
    override void IFoo.bar() {
      ...
    }
  }

2. Make auto classes useful and allow them to be returned from functions, passed to other functions, or be fields in other auto classes. Current restrictions make them useless. I think auto class should behave like object on stack, except default constructor (this() {...}) should be called it's declared and destructor when it goes out of scope. The object itself may reside on stack or heap, it doesn't really matter as long as stack semantics applies. Also, I would remove requirement that auto class variables must be explicitly declared "auto", so the following should be allowed:

auto class Foo { ... }
...
Foo x; // equivalent to "auto Foo x;"?

... or perhaps this:
Foo x; // equivalent to "auto Foo x = new Foo();"

Boris Kolar wrote:
> 1. Explicit interface implementation
>   interface IFoo {
>     void bar();
>   }
>   class Foo: IFoo {
>     ...
>     override void IFoo.bar() {
>       ...
>     }
>   }

I love this feature as implemented on C#. It's a nice way to keep the interface of a class clean from the user's stand point and still implement needed interfaces without using inner classes or other cruft.

Also, currently there's no way to implement two different interfaces that expose the same method if the behavior should be different.



> 2. Make auto classes useful and allow them to be returned from functions,
> passed to other functions, or be fields in other auto classes. Current
> restrictions make them useless. I think auto class should behave like object
> on stack, except default constructor (this() {...}) should be called it's
> declared and destructor when it goes out of scope. The object itself may
> reside on stack or heap, it doesn't really matter as long as stack semantics
> applies. Also, I would remove requirement that auto class variables must be
> explicitly declared "auto", so the following should be allowed:
> 
> auto class Foo { ... }
> ....
> Foo x; // equivalent to "auto Foo x;"?
> 
> .... or perhaps this:
> Foo x; // equivalent to "auto Foo x = new Foo();"

I think that this isn't the intended purpose of auto classes in D. They are with us to allow deterministic destruction of an instance at the end of scope.

If you are familiar with C# you should think of them as classes that implement IDisposable and are created inside a "using" statement. Their life-time spans until the closing brace and then the destructor is called. This is very useful technique, specially if you are using a Database or other resources witch are scarce.

The C# "using" statement it's more logical to me, but since "auto" allows stack allocation (thus improving performance) I'm very happy with it and my only complaint it's the type-inference issue.

== Quote from Julio César Carrascal Urquijo (jcesar@phreaker.net)'s article
> > auto class Foo { ... }
> > ....
> > Foo x; // equivalent to "auto Foo x;"?
> >
> > .... or perhaps this:
> > Foo x; // equivalent to "auto Foo x = new Foo();"
> I think that this isn't the intended purpose of auto classes in D. They
> are with us to allow deterministic destruction of an instance at the end
> of scope.
> If you are familiar with C# you should think of them as classes that
> implement IDisposable and are created inside a "using" statement. Their
> life-time spans until the closing brace and then the destructor is
> called. This is very useful technique, specially if you are using a
> Database or other resources witch are scarce.
> The C# "using" statement it's more logical to me, but since "auto"
> allows stack allocation (thus improving performance) I'm very happy with
> it and my only complaint it's the type-inference issue.

Deterministic destruction is exactly why I want auto classes. In C++, you also have deterministic destruction with structs/classes (in case of classes you must not use the "new" keyword). For example, this C++ code achieves the desired result of deterministic destruction:

#include "stdio.h"

class Test {
public:
	Test() {
		printf("ctor\n");
	}
	~Test() {
		printf("dtor\n");
	}
};
void test() {
	Test t;
}
int main() {
	printf("Running test\n");
	test();
	printf("Done testing\n");
	return 0;
}

In C++, however, "auto classes" are much more usefull because they can be passed as parameters, returned as results, or part of other classes. I'm 100% sure we can have both: usability without current restrictions and deterministic destruction.