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? Is the ambiguity an issue? If so, why should it not be the choice of the developer to decide this?
Another method with which one may achieve this is renaming S to something else (e.g. SImpl), and then defining a factory function called S. It works, but it seems like extra work considering the method described in the issue.

Also, to Jonathan, if you're lurking, I'd be interested if time's passage changed your opinion on this matter.

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.

On Monday, 26 October 2020 at 17:23:00 UTC, Q. Schroll wrote:
> 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.

Your elucidation is helpful, thank you! I've found this, too:

> Note: static opCall can be used to simulate struct constructors with no
> arguments, but this is not recommended practice. Instead, the preferred solution
> is to use a factory function to create struct instances.

Thus my argument has absolutely zero standing according to the spec.