• starcanopy (20/20) Oct 25 2020 The OP gives the following example:
• starcanopy (2/2) Oct 25 2020 Also, to Jonathan, if you're lurking, I'd be interested if time's
• Q. Schroll (14/28) Oct 26 2020 No, it wouldn't. You probably misunderstood, what @disable is
• starcanopy (4/22) Oct 26 2020 Thus my argument has absolutely zero standing according to the

starcanopy <starcanopy protonmail.com> writes:

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.

starcanopy <starcanopy protonmail.com> writes:

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

Q. Schroll <qs.il.paperinik gmail.com> writes:

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.

starcanopy <starcanopy protonmail.com> writes:

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.