using .init reliably

[Alex]

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