On Monday, 30 October 2017 at 15:03:25 UTC, Steven Schveighoffer
wrote:
This should also be disallowed. In order to know x.init means
what it normally means, we shouldn't allow overriding it. This
is the point of this thread, and the impetus for renaming of
TypeInfo.init().
Yeah... my problem is, that I don't know it at compile time.
The .init property is provided by the compiler, unless you
define it. It means the default value of the type.
I had something different in mind:
Either the "init" property belongs to the semantic of a type (in
this case a struct) or it doesn't.
If it does (I think, this is the case at this time point), then
it should be overloadable. However, restrictions can be applied,
like "one cannot override the standard (i. e. empty) provided
interface".
If it does not, then, an overload, like I did should not be
handled differently like every other overload, and the exception
in my example would be a bug.
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?
Once you override the property, the compiler will always use
that. You can't override a name and then have it fall back on
the default name for a different overload. D is very careful to
resolve symbol names in an unambiguous way.
Ok, I'm sorry for the confusion :)
My question was:
While I'm agreeing, that the init property should not be
overridden, could it be overloaded (with another interface)? And
why if not? As different interfaces fully disambiguate names...
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?)
What you can do is simply rename the static method. Certainly a
valid route to have a method to initialize the type variables.
So, using another interface is not the same, as using another
name? Or is the init property handled differently? ;)
Note that the way you have it, 'first' is a thread-local
variable, so it would have to be initialized in every thread.
Yes, this is the intention.
Thanks a lot :)
Alex
