On 5/17/13, Walter Bright <walter@digitalmars.com> wrote:
> I oppose this. D has a lot of nice features because of the .init property. Default constructors wreck that.

Would they? I'm thinking the process would be:

struct S
{
    int x;
    int y = void;

    this()  // hypothetical
    {
        // x would already be initialized to int.init here
        assert(x == int.init);

        // y is left uninitialized here
    }
}

Maybe that's already clear. But why is .init actually such a big problem? If it becomes arbitrarily expensive to call .init of a struct, well it's because it has to be - if the user really provided an expensive default ctor. But it's entirely the user's responsibility. So then .init can even throw, but throwing exceptions isn't a big deal. Is there some other problem?

A custom default ctor in a struct is one of the most asked for features. Just yesterday we spent several hours explaining to a C++ user why a default ctor doesn't work, and what .init is for. The whole conversation could have been avoided if D had support for custom default ctors for structs. This topic comes up very often in IRC and the forums.

On 5/17/13, Walter Bright <walter@digitalmars.com> wrote:
> I oppose this. D has a lot of nice features because of the .init property.
> Default constructors wreck that.

So much great feature like :
 - null all over the place.
 - Having NUllable and NonNullable in phobos. BTW, NonNullable is unable to ensure that it if effectively non nullable.
 - Having to check for .init state all over the place (which have a runtime cost, in addition to be error prone). RefCounted implementation is emblematic of that.

On 5/18/2013 12:08 AM, deadalnix wrote:
> On 5/17/13, Walter Bright <walter@digitalmars.com> wrote:
>> I oppose this. D has a lot of nice features because of the .init property.
>> Default constructors wreck that.
>
> So much great feature like :
>   - null all over the place.
>   - Having NUllable and NonNullable in phobos. BTW, NonNullable is unable to
> ensure that it if effectively non nullable.
>   - Having to check for .init state all over the place (which have a runtime
> cost, in addition to be error prone). RefCounted implementation is emblematic of
> that.

What default would you use for non-null pointers?

On Saturday, May 18, 2013 00:14:30 Walter Bright wrote:
> What default would you use for non-null pointers?

It would basically have to @disable init, because you can't have a default for non-nullable pointers. It just wouldn't make sense. Pretty much the whole point of them is to guarantee that they've been initialized with a valid value.

- Jonathan M Davis

On Saturday, 18 May 2013 at 07:14:29 UTC, Walter Bright wrote:
> What default would you use for non-null pointers?

Compile time error as a default sound like a nice option. Probably too late now, but that is where most language are going now, and having done quite a lot of java myself, I can guarantee you that it make sense.

On Sat, 18 May 2013 09:14:30 +0200, Walter Bright <newshound2@digitalmars.com> wrote:

> On 5/18/2013 12:08 AM, deadalnix wrote:
>> On 5/17/13, Walter Bright <walter@digitalmars.com> wrote:
>>> I oppose this. D has a lot of nice features because of the .init property.
>>> Default constructors wreck that.
>>
>> So much great feature like :
>>   - null all over the place.
>>   - Having NUllable and NonNullable in phobos. BTW, NonNullable is unable to
>> ensure that it if effectively non nullable.
>>   - Having to check for .init state all over the place (which have a runtime
>> cost, in addition to be error prone). RefCounted implementation is emblematic of
>> that.
>
> What default would you use for non-null pointers?

Damnit, I thought we'd gotten through to you. non-null pointers have no
default, and it is a compile-time error not to initialize them.

-- 
Simen

On 5/18/13 7:13 AM, Simen Kjaeraas wrote:
> On Sat, 18 May 2013 09:14:30 +0200, Walter Bright
> <newshound2@digitalmars.com> wrote:
>
>> On 5/18/2013 12:08 AM, deadalnix wrote:
>>> On 5/17/13, Walter Bright <walter@digitalmars.com> wrote:
>>>> I oppose this. D has a lot of nice features because of the .init
>>>> property.
>>>> Default constructors wreck that.
>>>
>>> So much great feature like :
>>> - null all over the place.
>>> - Having NUllable and NonNullable in phobos. BTW, NonNullable is
>>> unable to
>>> ensure that it if effectively non nullable.
>>> - Having to check for .init state all over the place (which have a
>>> runtime
>>> cost, in addition to be error prone). RefCounted implementation is
>>> emblematic of
>>> that.
>>
>> What default would you use for non-null pointers?
>
> Damnit, I thought we'd gotten through to you. non-null pointers have no
> default, and it is a compile-time error not to initialize them.

This is what I call the "low potential energy mental block". Very hard to get out of.

Andrei

On Saturday, 18 May 2013 at 14:22:44 UTC, Andrei Alexandrescu wrote:
> This is what I call the "low potential energy mental block". Very hard to get out of.
>

Can you explain this please ?

On 5/18/13, Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org> wrote:
> This is what I call the "low potential energy mental block". Very hard to get out of.

Well in any case, I'd like to gather all intel on why it's bad to allow a default ctor so we can put it in the documentation as a rationale. It will avoid endless discussions.

On Saturday, 18 May 2013 at 14:43:30 UTC, Andrej Mitrovic wrote:
> On 5/18/13, Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org> wrote:
>> This is what I call the "low potential energy mental block". Very hard
>> to get out of.
>
> Well in any case, I'd like to gather all intel on why it's bad to
> allow a default ctor so we can put it in the documentation as a
> rationale. It will avoid endless discussions.

I think when you collect arguments why it is bad to have a default ctor, you will found how easily they are beaten by contraarguments. Endless discussions comes from community disagree with Walter, not because of endless flow of people asking same question, getting same answer and quiting discussion repeteadly.