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