On 5/18/13 10:30 AM, deadalnix wrote:
> 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 ?

Happens to me a lot, and am fighting it for dear life. Occurs when a person:

1. Doesn't understand something

2. Doesn't understand (s)he doesn't understand that something

3. Consequently forms a belief there is no lack of understanding

4. Thus has little motivation to change opinion in the matter and see things differently, since there's no need for that (i.e. enters a low potential energy that's difficult to get out of)

5. Whenever discussing the matter, amasses further misunderstood pieces of evidence due to confirmation bias, therefore furthering the depth of the potential hole

Such phenomena are widespread and used most visibly in sitcoms in the following classic pattern: two people discuss a matter in which they make different assumptions about a context (e.g. one thinks it's about a person, the other thinks it's about a bottle). During the discussion, both use pieces and tidbits of ambiguous language from the other to further consolidate their belief the topic is indeed what they thought it would be. The watcher, knowing the context of both characters, derives enjoyment figuring how the same conversation may be viewed in completely different ways.

Consider the following classics that Walter, myself, or sometimes both have been going through:

- virtual machines are a crock
- non-null pointers are meh
- generic is better than OOP
- can't/shouldn't check for arithmetic overflow

Some past ones that we fixed:

- string lambdas are just fine
- can't have many integral types without unsafe casts
- can't fix a < b < c to stay C-compatible and meaningful


Andrei

On 5/18/2013 12:30 AM, deadalnix wrote:
> 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.

D has that:

   @disable this();

which is not the same thing as allowing default constructors. See:

http://d.puremagic.com/issues/show_bug.cgi?id=10102

On 5/18/2013 4: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.
>

See my reply to deadalnix.

On Saturday, 18 May 2013 at 18:41:49 UTC, Walter Bright wrote:
> On 5/18/2013 12:30 AM, deadalnix wrote:
>> 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.
>
> D has that:
>
>    @disable this();
>
> which is not the same thing as allowing default constructors. See:
>
> http://d.puremagic.com/issues/show_bug.cgi?id=10102

struct S
{
   int a;
   @disable this();
   this(int) { a = 1; }
   ~this() { assert(a !is 0); }
}

enum E : S { A = S.init }

union U
{
   S s;
   this(this) { assert (s.a !is 0); }
   ~this() { assert (s.a !is 0); }
}

void foo(out S s, out E e, out U u) { }

void main()
{
   S[] arr;
   arr.length = 5; // compiles
   E[] e;
   e.length = 5; // compiles
   S[1] x = (S[1]).init; // compiles
   U[] u;
   u.length = 5; //compiles
   foo(arr[0], e[0], u[0]); // compiles
}

@disable this(); commitments are cheap.

On 5/18/2013 1:05 PM, Maxim Fomin wrote:
> @disable this(); commitments are cheap.

http://d.puremagic.com/issues/show_bug.cgi?id=10115

On Saturday, 18 May 2013 at 18:41:49 UTC, Walter Bright wrote:
> On 5/18/2013 12:30 AM, deadalnix wrote:
>> 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.
>
> D has that:
>
>    @disable this();
>
> which is not the same thing as allowing default constructors. See:
>
> http://d.puremagic.com/issues/show_bug.cgi?id=10102

I played with that. It ensure nothing, convey intent at best.

On 5/18/2013 1:12 PM, deadalnix wrote:
> I played with that. It ensure nothing, convey intent at best.

Please file bug reports for any holes in it.

On Saturday, 18 May 2013 at 20:19:11 UTC, Walter Bright wrote:
> On 5/18/2013 1:12 PM, deadalnix wrote:
>> I played with that. It ensure nothing, convey intent at best.
>
> Please file bug reports for any holes in it.

Many are, but I think that isn't the point we are discussing here.

Removing all holes in @disable this will require the same sacrifices at the ends than default constructor would. For isntance, what should happen in this case :

S[] ss;
ss.length = 42;

if S has @disable this ?

On 5/18/2013 1:22 PM, deadalnix wrote:
> Many are, but I think that isn't the point we are discussing here.
>
> Removing all holes in @disable this will require the same sacrifices at the ends
> than default constructor would. For isntance, what should happen in this case :
>
> S[] ss;
> ss.length = 42;
>
> if S has @disable this ?

Already reported:

http://d.puremagic.com/issues/show_bug.cgi?id=10115

On Sat, 18 May 2013 20:42:32 +0200, Walter Bright <newshound2@digitalmars.com> wrote:

> On 5/18/2013 4:13 AM, Simen Kjaeraas wrote:
>
>> On Sat, 18 May 2013 09:14:30 +0200, Walter Bright <newshound2@digitalmars.com>
>> wrote:
>>
>>> 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.
>>
>
> See my reply to deadalnix.

On Sat, 18 May 2013 20:41:48 +0200, Walter Bright <newshound2@digitalmars.com> wrote:

> D has that:
>
>     @disable this();
>
> which is not the same thing as allowing default constructors. See:
>
> http://d.puremagic.com/issues/show_bug.cgi?id=10102

Oh, absolutely. I'm not at all claiming they are (Nor do I think others claim
that). It's just it was so hard to make you see the value of non-nullable
pointers, and I feared you'd regressed.

@disable this is awesome, really. And you're right that it's even better than
simple non-nullable pointers. Lastly, it's great that it's getting fixes. It's
been one of my favorite non-working features. :p

In a way, I fear that we'll end up like C++, with bare pointers/references
being considered experts-only and 'special use', and everyone will use smart
pointers instead.

-- 
Simen