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

On 10/30/17 11:39 AM, Alex wrote:
> 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.

You know it at language 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.

It belongs to the language. The init property should be only allowed by the language. It doesn't need to be a keyword, but it should not be allowed as a member function or field.

> 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.

It should not be overridable. Otherwise, we cannot reason about low-level concepts that build types from scratch.

>> 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...

No, it shouldn't be overridden. Why not? Because so much generic code assumes that T.init or t.init (instance t of type T) means "the compile-time defined initializer for type T", and to allow any overriding of this would be hugely damaging to such functions.

Yes, I understand that you want to not override the getter init property, but simply choose another name for your function, and it should work just fine. I recommend "initializer" or "initialize" or "make".

>> 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? ;)

In D, when you have overloads at different levels of priority, it doesn't matter. Whatever has the highest priority owns all the overloads.

For instance:

struct S
{
   void foo(int x) {...}
}

void foo(S s, string x) {...}

void main()
{
   S s;
   s.foo("hi"); // error
}

My contention is that the language definition of init should have the highest priority.

FYI: https://issues.dlang.org/show_bug.cgi?id=17954

-Steve

On Tuesday, 31 October 2017 at 02:24:48 UTC, Steven Schveighoffer wrote:
>> Yeah... my problem is, that I don't know it at compile time.
>
> You know it at language time :)
>
:)

> The .init property is provided by the compiler, unless you define it. It means the default value of the type.
Here, I'm totally with you.

> It belongs to the language. The init property should be only allowed by the language. It doesn't need to be a keyword, but it should not be allowed as a member function or field.
Take for example, the sizeof property. It can't be redefined.
Should be the init property of the same kind?
Should it be not redefinable at all, or only to guarantee, to get a valid value? And if the latter, does it matter whether it as evaluable at compile time?
If the former - I have no problem with this, it is just a possibility to init an object in special cases.

> In D, when you have overloads at different levels of priority, it doesn't matter. Whatever has the highest priority owns all the overloads.
>
> For instance:
>
> struct S
> {
>    void foo(int x) {...}
> }
>
> void foo(S s, string x) {...}
>
> void main()
> {
>    S s;
>    s.foo("hi"); // error
> }
>
Ok, I was not aware of this... And this quiet my mind a lot :)

> My contention is that the language definition of init should have the highest priority.
>
> FYI: https://issues.dlang.org/show_bug.cgi?id=17954

Ok, cool. Thanks for that, and think, the first comment by Jakob goes in the same direction, as I'm thinking of.

So, my current problem is solved by your code sample and the different levels of priority hint.

Thanks a a lot :)