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
