Could someone please explain what you would use this for to an old man rooted in C++, but who loves D.

Where does it fit in relative to 42?

;=(

Steve

On Thursday, 27 February 2014 at 18:10:38 UTC, Steve Teale wrote:
> Could someone please explain what you would use this for to an old man rooted in C++, but who loves D.
>
> Where does it fit in relative to 42?
>
> ;=(
>
> Steve

It's for explicit initialization:

struct Foo { }

Foo f; // no problem

struct Bar {
    @disable this();
}

Bar b; // error

Basically, disabling the default constructor just forces the user to think about what they want there to initialize it, which also gives you a chance to check their values or funnel them toward a particular constructor/factory method.

They can still choose to explicitly leave it unitialized with =void, or call a constructor with some value.

Just when you write

Foo f;

and the compiler complains that default constructor is disabled, now you have to actually think about what to do next. If you consult the docs, it might say "use Foo.create() instead" and now you know. Or you might give it some value that makes sense.

On Thursday, 27 February 2014 at 18:13:43 UTC, Namespace wrote:
> On Thursday, 27 February 2014 at 18:10:38 UTC, Steve Teale wrote:
>> Could someone please explain what you would use this for to an old man rooted in C++, but who loves D.
>>
>> Where does it fit in relative to 42?
>>
>> ;=(
>>
>> Steve
>
> It's for explicit initialization:
>
> struct Foo { }
>
> Foo f; // no problem
>
> struct Bar {
>     @disable this();
> }
>
> Bar b; // error

So it is just a reminder that you need to initialize Bar in some specific way?

On Thursday, 27 February 2014 at 18:26:10 UTC, Steve Teale wrote:
> On Thursday, 27 February 2014 at 18:13:43 UTC, Namespace wrote:
>> On Thursday, 27 February 2014 at 18:10:38 UTC, Steve Teale wrote:
>>> Could someone please explain what you would use this for to an old man rooted in C++, but who loves D.
>>>
>>> Where does it fit in relative to 42?
>>>
>>> ;=(
>>>
>>> Steve
>>
>> It's for explicit initialization:
>>
>> struct Foo { }
>>
>> Foo f; // no problem
>>
>> struct Bar {
>>    @disable this();
>> }
>>
>> Bar b; // error
>
> So it is just a reminder that you need to initialize Bar in some specific way?

pretty much, yes.

More precisely, it disables the implicit no-op default constructor, forcing the user to use a different one.

On Thursday, 27 February 2014 at 18:26:10 UTC, Steve Teale wrote:
> On Thursday, 27 February 2014 at 18:13:43 UTC, Namespace wrote:
>> On Thursday, 27 February 2014 at 18:10:38 UTC, Steve Teale wrote:
>>> Could someone please explain what you would use this for to an old man rooted in C++, but who loves D.
>>>
>>> Where does it fit in relative to 42?
>>>
>>> ;=(
>>>
>>> Steve
>>
>> It's for explicit initialization:
>>
>> struct Foo { }
>>
>> Foo f; // no problem
>>
>> struct Bar {
>>    @disable this();
>> }
>>
>> Bar b; // error
>
> So it is just a reminder that you need to initialize Bar in some specific way?

aye

On 2/28/2014 3:10 AM, Steve Teale wrote:
> Could someone please explain what you would use this for to an old man
> rooted in C++, but who loves D.
>
> Where does it fit in relative to 42?
>
> ;=(
>
> Steve

I use it for namespaces.

struct Foo {
   @disable this();
   @disable this( this );

   private static {
      // members
   }

   public static {
      // methods
   }
}

Ideally, I'd love for the compiler to pick up on this idiom and not generate any typeinfo in this situation.

On Friday, 28 February 2014 at 01:16:41 UTC, Mike Parker wrote:
> On 2/28/2014 3:10 AM, Steve Teale wrote:
>> Could someone please explain what you would use this for to an old man
>> rooted in C++, but who loves D.
>>
>> Where does it fit in relative to 42?
>>
>> ;=(
>>
>> Steve
>
> I use it for namespaces.
>
> struct Foo {
>    @disable this();
>    @disable this( this );
>
>    private static {
>       // members
>    }
>
>    public static {
>       // methods
>    }
> }
>
> Ideally, I'd love for the compiler to pick up on this idiom and not generate any typeinfo in this situation.

For such namespaces I use final abstract classes:

final abstract class Foo {
static:
    // members
}

Mike Parker:

> Ideally, I'd love for the compiler to pick up on this idiom and not generate any typeinfo in this situation.

Is this in Bugzilla somewhere? If it's a good idea then it could and should go in Bugzilla.

Bye,
bearophile

On Friday, 28 February 2014 at 01:16:41 UTC, Mike Parker wrote:
> Ideally, I'd love for the compiler to pick up on this idiom and not generate any typeinfo in this situation.

Ideally one should use modules as namespaces :P