Issue 14087: @disable this hides static opCall

[starcanopy]

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.