using .init reliably

Alex sascha.orlov at gmail.com
Tue Oct 31 10:08:14 UTC 2017


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 :)


More information about the Digitalmars-d-learn mailing list