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