using .init reliably

Steven Schveighoffer schveiguy at yahoo.com
Tue Oct 31 02:24:48 UTC 2017


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


More information about the Digitalmars-d-learn mailing list