Walter is about to fix an old bug [1] so that invariants are now called before destruction and for non-default construction.

A remaining question is whether invariants should also be called for default construction [2].

[1]: https://github.com/D-Programming-Language/dmd/pull/4136
[2]: https://issues.dlang.org/show_bug.cgi?id=519#c11

On 11/17/14 3:02 PM, Martin Nowak wrote:
> Walter is about to fix an old bug [1] so that invariants are now called
> before destruction and for non-default construction.

This sounds good.

> A remaining question is whether invariants should also be called for
> default construction [2].

I'd say no. There are better ways to test for valid data in the .init version of the object/struct that don't involve a runtime check.

-Steve

On 11/17/2014 12:32 PM, Steven Schveighoffer wrote:
> On 11/17/14 3:02 PM, Martin Nowak wrote:
>> Walter is about to fix an old bug [1] so that invariants are now called
>> before destruction and for non-default construction.
>
> This sounds good.
>
>> A remaining question is whether invariants should also be called for
>> default construction [2].
>
> I'd say no. There are better ways to test for valid data in the .init version of
> the object/struct that don't involve a runtime check.

Not only that, the runtime check would occur every time an object is created, yet the .init will always be the same. Doing this check would, I fear, cause people to disable invariants as not worth the expense.

On 11/17/14 3:51 PM, Walter Bright wrote:
> On 11/17/2014 12:32 PM, Steven Schveighoffer wrote:
>> On 11/17/14 3:02 PM, Martin Nowak wrote:
>>> Walter is about to fix an old bug [1] so that invariants are now called
>>> before destruction and for non-default construction.
>>
>> This sounds good.
>>
>>> A remaining question is whether invariants should also be called for
>>> default construction [2].
>>
>> I'd say no. There are better ways to test for valid data in the .init
>> version of
>> the object/struct that don't involve a runtime check.
>
> Not only that, the runtime check would occur every time an object is
> created, yet the .init will always be the same. Doing this check would,
> I fear, cause people to disable invariants as not worth the expense.

It's already not worth the expense for Objects, which Object.invariant for every function call, even if you don't define one.

-Steve

On 11/17/14 4:09 PM, Steven Schveighoffer wrote:
>
> ... which Object.invariant for every function call ...
>

which *calls* Object.invariant for every function call

-Steve

On Monday, 17 November 2014 at 20:02:36 UTC, Martin Nowak wrote:
> Walter is about to fix an old bug [1] so that invariants are now called before destruction and for non-default construction.
>
> A remaining question is whether invariants should also be called for default construction [2].
>
> [1]: https://github.com/D-Programming-Language/dmd/pull/4136
> [2]: https://issues.dlang.org/show_bug.cgi?id=519#c11

We don't have default constructor. So we need to be able to rely
on a struct being in a invalid state at default construction.

Solution obviously being to have default constructor and to run
the invariant after default construction.

On Tuesday, 18 November 2014 at 00:51:03 UTC, deadalnix wrote:
> On Monday, 17 November 2014 at 20:02:36 UTC, Martin Nowak wrote:
>> Walter is about to fix an old bug [1] so that invariants are now called before destruction and for non-default construction.
>>
>> A remaining question is whether invariants should also be called for default construction [2].
>>
>> [1]: https://github.com/D-Programming-Language/dmd/pull/4136
>> [2]: https://issues.dlang.org/show_bug.cgi?id=519#c11
>
> Solution obviously being to have default constructor and to run
> the invariant after default construction.

We do have them for classes.

On Monday, 17 November 2014 at 20:51:36 UTC, Walter Bright wrote:
> Not only that, the runtime check would occur every time an object is created, yet the .init will always be the same. Doing this check would, I fear, cause people to disable invariants as not worth the expense.

If it's init data it is know at compile time right?
Couldn't we try to run the invariant for the init state once in CTFE?

On 17.11.2014 21:02, Martin Nowak wrote:
> Walter is about to fix an old bug [1] so that invariants are now called
> before destruction and for non-default construction.
>
> A remaining question is whether invariants should also be called for
> default construction [2].
>
> [1]: https://github.com/D-Programming-Language/dmd/pull/4136
> [2]: https://issues.dlang.org/show_bug.cgi?id=519#c11

I remember having an invariant on a tree structure checking consistency by verifying the children and parent references. This crashed when adding a destructor. With the proposed change it will always crash.

The problem is that the destructors of the tree nodes are called in arbitrary order when they are collected by the GC. Class instances are also made invalid after calling the destructor (the vtbl is zeroed).

I wonder if

- such invariants are invalid,
- the GC should bypass the invariant when calling the destructor
- or we should never call the invariant with the destructor?

"Rainer Schuetze"  wrote in message news:m4eu6v$trq$1@digitalmars.com...

> I remember having an invariant on a tree structure checking consistency by verifying the children and parent references. This crashed when adding a destructor. With the proposed change it will always crash.
>
> The problem is that the destructors of the tree nodes are called in arbitrary order when they are collected by the GC. Class instances are also made invalid after calling the destructor (the vtbl is zeroed).
>
> I wonder if
>
> - such invariants are invalid,
> - the GC should bypass the invariant when calling the destructor
> - or we should never call the invariant with the destructor?

I think the 'correct' solution is to check the invariants before any of the parts are destroyed.