Issue 14087: @disable this hides static opCall

[Q. Schroll]

On Monday, 26 October 2020 at 02:40:01 UTC, starcanopy wrote:
> The OP gives the following example:
>
> struct S
> {
>     @disable this();
>
>     static void opCall()
>     {}
> }
>
> The compiler will rebuke you: "Error: struct deneme.S static 
> opCall is hidden by constructors and can never be called"
>
> To Kenji and Walter, this is intended behavior, and the former 
> is skeptical of such a pattern. But why? Denoting a function as 
> @disable implies its use is verboten; it's obvious. Thus, if an 
> opCall with no parameters is defined, would it not be logical 
> that S() would fall to the aforementioned opCall?

No, it wouldn't. You probably misunderstood, what @disable is 
intended to do. It will not remove the overload it is declaring; 
in fact, it may introduce that overload in the first place. It 
does not change the precedence that overload takes.
As I understand it, this is intended. A @disable'd method can be 
used on a type to document that obj.method() is not supposed to 
work. It can be used to make compiler-generated functions "not 
work" (thank Andrei for this phrase) because there's no way to 
make them "not there".
I agree that one could want something like you suggest, i.e. 
removing this(), but if @disable did that, it would be an odd 
corner/special case of its use.
I hope I could bring some light to you.