On Monday, 9 February 2015 at 20:15:28 UTC, Jonathan M Davis
wrote:
On Monday, February 09, 2015 13:29:22 Steven Schveighoffer via
Digitalmars-d-learn wrote:
On 2/8/15 2:57 PM, Jonathan M Davis via Digitalmars-d-learn
wrote:
> On Sunday, February 08, 2015 17:51:09 bearophile via
> Digitalmars-d-learn wrote:
>> fra:
>>
>>> However making it a compiler error would be far, far better
>>
>> I think this can be filed in Bugzilla as diagnostic
>> enhancement:
>>
>>
>> class Foo {
>> @disable this();
>> this(int i) {}
>> }
>> void main() {}
>
> The compiler should probably just give you an error telling
> you that
> disabling the default constructor on classes is illegal. And
> since no
> default constructor is automatically declared if you declare
> another
> constructor, there isn't even any point in disabling the
> default constructor
> (which is probably why no one has been complaining about
> this). @disable
> this() only makes sense on structs.
Why? I think it's perfectly acceptable.
What should be illegal is if you extend Foo and don't @disable
this on
the derivative.
Why would it we even allow it? What benefit is there? It's
meaningless.
@disable this(); is for disabling the init property on structs.
Classes
themselves have no init values - and their references have null
as their
init value.
No, `@disable this()` does _not_ disable the init property on
structs. It disables default, i.e. argument-less construction.
Which is analogous to `new MyClass()`. It makes perfect sense to
disable argument-less construction in classes, just like with
structs. (They are of course different, in that struct default
constructors don't "do" anything, but that's not relevant here.)
The default constructor already follows sensible rules where
it's not
generated if another constructor is declared, and derived
classes have to
call a base class constructor if the base class doesn't have a
default
constructor.
Therefore `@disable this()` is redundant in that case, but still
meaningful.
