View mode: basic / threaded / horizontal-split · Log in · Help
October 22, 2006
Two feature requests
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();"
October 23, 2006
Re: Two feature requests
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.
October 23, 2006
Re: Two feature requests
== 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.
Top | Discussion index | About this forum | D home