Sorry for dig out this posting, but this one is more recent, than
http://forum.dlang.org/thread/k15of5$22ub$1...@digitalmars.com?page=1
and my question is just beyond the two:
I'm with you, regarding that the standard init property should
not be overridden. But how about to override it with a custom
init function, which has a different interface?
An example:
/// --- code --- ///
void main()
{
int first = 5;
//auto s0 = S.init; // this line (4) yields an error:
// function app.S.init (int fParam) is not callable using
argument types ()
S.init(first);
int second = 2;
auto s = S(second);
assert(s.first == first);
assert(s.second == second);
}
struct S
{
static int first;
int second;
// I'm aware of the fact, that nobody should redefine init()
like:
// static auto init() { writeln("oh-oh..."); }
static void init(int fParam) { first = fParam; }
this(int sParam) { second = sParam; }
}
/// --- code --- ///
My question has some components:
1. If this also should be disallowed: why, as it could be
possible, that I'm not aware of existence of any init property of
every struct.
2. Regardless of the result of the first question, line 4 of the
example yields an error, although I didn't touch the standard
init property. Why?
3. A practical aspect: What I try to solve is a two-stage
initialization of an object. I know, this should be avoided. In
order to do this, I try to separate the initializations of the
type and its objects.
(By the way, is this the right way to go?)
Of course, I could use an external function, say
prepareType(S)(int fParam)
to do so, and this is the place, where I remembered the old
posting and found the current one.
As we are already beyond 2.075, are there known tickets about the
disabling of the ability to override the init property, where I
can post the bug of the second question, in case it is one?
4. The chipped in question in the previous paragraph :)
