Bug 7066 – You can redefine .init and .stringof without error

The .init and .stringof properties of types can be redefined. A lot of code depends on the definition of .init, so being able to change this breaks a lot of Phobos. class Foo { static immutable int init; static immutable int stringof; } int x = Foo.init; int y = Foo.stringof; DMD should give an error just like it does for .sizeof, .alignof, and .mangleof

They're actually supposed to be overridable at the moment. I had thought there might be a use for this, but so far none have materialized. But to change it is an enhancement request.

How about it is disable until a compelling argument is provided. Or if someone complains during a beta.

*** Issue 8817 has been marked as a duplicate of this issue. ***

*** Issue 13202 has been marked as a duplicate of this issue. ***

I would like to see this disable or if we don't want to break backwards compatibility for this, we should have the compiler issue a warning. As it stands at the moment, the behavior causes more harm then good.

(In reply to Walter Bright from comment #1) > They're actually supposed to be overridable at the moment. I had thought > there might be a use for this, but so far none have materialized. > ... There is one obvious use case: struct S{ @disable enum init=0; } It would be better to have a specific feature here though. E.g. struct S{ @disable init; }

(In reply to timon.gehr from comment #6) > (In reply to Walter Bright from comment #1) > > They're actually supposed to be overridable at the moment. I had thought > > there might be a use for this, but so far none have materialized. > > ... > > There is one obvious use case: > > struct S{ @disable enum init=0; } > > It would be better to have a specific feature here though. E.g. > > struct S{ @disable init; } I would have thought that struct S{ @disable this(); } would do that in addition to making S s; illegal. I was surprised to find out that it didn't. But if there _is_ a good reason for S s = S.init; to still work with @disable this(); was used (though I certainly can't think of one), then @disable init; should probably imply @disable this();.

(In reply to timon.gehr from comment #6) > It would be better to have a specific feature here though. E.g. > > struct S{ @disable init; } struct S{ @disable void init(); } ?

I encountered this problem as well while porting a C++ library to D. It took a while to diagnose, but I eventually found out that the mere existence of a function named "init" caused the RefAppender I used in a totally unrelated function to break. Example program: ``` import std.array; struct S1 { // The mere presence of this method causes the error, deleting it fixes the error. void init(string p1, int p2, int p3) { } } struct S2 { S1[] a; RefAppender!(int[]) getAppender() { return appender(&a); } } void main() { } ``` The actual error produced is obvious only because the arguments I put on init in this example, but normally it's pretty bizarre: ``` /dlang/dmd/linux/bin64/../../src/phobos/std/array.d(2907): Error: cannot have array of `void(string, int, int)` /dlang/dmd/linux/bin64/../../src/phobos/std/array.d(2976): Error: cannot have array of `inout void(string, int, int)` /dlang/dmd/linux/bin64/../../src/phobos/std/array.d(3369): Error: template instance `std.array.Appender!(S1[])` error instantiating /dlang/dmd/linux/bin64/../../src/phobos/std/array.d(3879): instantiated from here: `RefAppender!(S1[])` onlineapp.d(12): instantiated from here: `appender!(S1[]*, S1)` /dlang/dmd/linux/bin64/../../src/phobos/std/array.d(3429): Error: cannot have array of `inout void(string, int, int)` ```

*** Issue 14237 has been marked as a duplicate of this issue. ***

struct S { string stringof; } // Issue 14237 class MyClass { void init() {}; } `init` and `stringof` should be required to be `static`, as they are expected to work without an instance. They should probably not be allowed to be `void` functions either.

*** Issue 1412 has been marked as a duplicate of this issue. ***

*** Issue 17465 has been marked as a duplicate of this issue. ***

THIS ISSUE HAS BEEN MOVED TO GITHUB https://github.com/dlang/dmd/issues/18386 DO NOT COMMENT HERE ANYMORE, NOBODY WILL SEE IT, THIS ISSUE HAS BEEN MOVED TO GITHUB