On Monday, February 09, 2015 15:25:14 Steven Schveighoffer via Digitalmars-d-learn wrote:
> Well, if I do this:
>
> class C {}
>
> I can do this:
>
> new C();
>
> Mechanisms to disable this are kind of awkward. I can define this() as private, but that doesn't help for intra-module calls.
>
> static class C doesn't work.
>
> It really is only useful in the case where you don't want to define a constructor. Which probably means -- you don't want to use a class anyway ;)
>
> But for completeness, it seems like I should be able to have the option of disabling something the compiler does by default. Even if it's next to useless.

I suppose that it makes sense if you want to make it so that the class can't be constructed (and actually, now that I look at it, that's what std.datetime.Clock does), but if another constructor has been declared, then it should be probably be disallowed at compile time - especially if it's resulting in a linker error.

- Jonathan M Davis

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.

On Tuesday, February 10, 2015 11:16:21 via Digitalmars-d-learn wrote:
> On Monday, 9 February 2015 at 20:15:28 UTC, Jonathan M Davis
> > 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.)

Well, then that's a change. It used to be that @disable this() completely disabled the init property. So, I guess now it just disables its implicit use, which probably screws up its use for stuff like a NonNullable (which is why it exists in the first place), but having types without an init property definitely would make things nasty with generic code (which is where we sat for a while, I believe).

- Jonathan M Davis

On 2/10/15 12:15 PM, Jonathan M Davis via Digitalmars-d-learn wrote:
> On Tuesday, February 10, 2015 11:16:21 via Digitalmars-d-learn wrote:
>> On Monday, 9 February 2015 at 20:15:28 UTC, Jonathan M Davis
>>> 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.)
>
> Well, then that's a change. It used to be that @disable this() completely
> disabled the init property. So, I guess now it just disables its implicit
> use, which probably screws up its use for stuff like a NonNullable (which is
> why it exists in the first place), but having types without an init property
> definitely would make things nasty with generic code (which is where we sat
> for a while, I believe).

No, it's not a change. You could always do:

S s = S.init;

What the feature disabled is this:

S s;

-Steve