在 Mon, 30 Nov 2009 09:35:17 +0800，Denis Koroskin <[email protected]>
写道:
On Mon, 30 Nov 2009 03:18:27 +0300, Andrei Alexandrescu
<[email protected]> wrote:
Denis Koroskin wrote:
On Mon, 30 Nov 2009 02:20:40 +0300, bearophile
<[email protected]> wrote:
Andrei Alexandrescu:
c) If a class doesn't define any constructors but does add at least a
non-static field -> undecided.
Does 'undecided' mean 'compile-time error'?"
Bye,
bearophile
I think it means they are not decided whether it should inherit
constructors.
Back on topic, I do think inheriting constructors is a good idea,
even in presence of additional fields (why not?)
I also think constructor inheritance could be implemented without any
changes to the language the following way:
this(Args...)(Args args) if (__traits(compiles, super(args)))
{
super(args);
// initialize additional fields, if any present
// and/or do some post-construction logic
}
Why create new rules? :)
Alas, that doesn't work because of ref and out arguments. I actually
think it's a language bug that it's impossible to implement perfect
forwarding.
Andrei
Well, intuitively it should be implemented this way:
class Foo { /* a few different ctors */ }
class Bar : Foo
{
alias super.this this; // the same way you do
// "alias super.someMethod someMethod;" to add someMethod into
current scope
}
Unfortunately, this conflicts with alias this feature. If we could
rename constructors from "this" to "ctor", we could use it with no
ambiguity:
I think opDispatch should be able to simulate the current alias this
feature. And current alias this should be something work like the example
you provided.
class Bar : Foo
{
alias super.ctor ctor;
ctor(Other other)
{
// ... shoudn't conflict with existing ctors (or should it?)
}
}
This would also help getting rid an ugly "__ctor" identifier which is
used as placement new:
void[] mem = allocate!(T);
// old style
T.__ctor(mem);
// new style
T.ctor(mem);
--
使用 Opera 革命性的电子邮件客户程序: http://www.opera.com/mail/
