https://issues.dlang.org/show_bug.cgi?id=12277

Nick Treleaven <ntrel-public@yahoo.co.uk> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |ntrel-public@yahoo.co.uk

--- Comment #1 from Nick Treleaven <ntrel-public@yahoo.co.uk> ---
Note that the error on your code is correct as you define this(int) - see bug
12194.

This issue is not the same as that one, as @disable this alone triggers the error:

struct S
{
    @disable this();

    static S opCall(){
        return S.init;
    }
}

--

https://issues.dlang.org/show_bug.cgi?id=12277

Vladimir Panteleev <dlang-bugzilla@thecybershadow.net> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|---                         |WONTFIX
           Severity|normal                      |enhancement

--- Comment #2 from Vladimir Panteleev <dlang-bugzilla@thecybershadow.net> ---
(In reply to Remo from comment #0)
> But the default ctor is disabled.

Fairly sure that's not relevant.

As I understand, @disable does not make a symbol invisible to the compiler, it makes it so that invoking it (one way or another) becomes forbidden. So, annotating the constructor with @disable will not make it prefer the static opCall.

I suppose that, as an enhancement, the compiler could be made to prefer the static opCall when the constructor is present but disabled, but this is likely to complicate the language/implementation for very little gain, especially considering that the simple workaround of writing a factory function (as the error message suggests) is available.

Note that if you give the opCall method arguments (e.g. `static S
opCall(int)`), the code is accepted, so the problem occurs only with the
questionable ambiguous S() syntax.

As this was filed and has been inactive for over 3 years ago, I'll close this, but feel free to reopen if you disagree.

--