Thread overview
invariant constancy: revisited
Mar 14, 2014
Jakob Ovrum
Mar 15, 2014
Andrej Mitrovic
Mar 15, 2014
Daniel Murphy
Mar 15, 2014
Jakob Ovrum
Mar 15, 2014
Andrej Mitrovic
Mar 15, 2014
Daniel Murphy
Mar 15, 2014
Andrej Mitrovic
March 14, 2014
Here we go again.

Back in 2012, invariants were misguidedly made const by default without going through any review whatsoever, breaking a ton of code in the process[1]. That means bitwise constancy is enforced for the this-reference in the body of the invariant. There is no way to opt out of this.

The well-intentioned argument is that invariants should not have side effects, which I wholeheartedly agree with. The problem is measuring side effects in terms of bitwise constancy and not logical constancy. I was using logically constant invariants at the time, but had to abandon them because of this change (again, no way to opt out). Also, debug code inside invariants is also hampered by bitwise const.

Pull requests were since made to revert the change, while allowing invariants to be type-qualified explicitly to enforce bitwise-constancy[1][2]. They eventually rot away, and now two years later, invariants are still artificially limited by bitwise const; as I had stopped using invariants, I never noticed.

I think we're running out of time to fix this, if we haven't already. Specifically, the reversion was never commented on by Walter, though Andrei did seem supportive. Please approve the change. Hopefully this is the time to reclaim invariants ;)

[1] https://github.com/D-Programming-Language/dmd/commit/3c138718365541cde67abbdcfc031d755c3a7969
[2] https://github.com/D-Programming-Language/dmd/pull/1073
[3] https://github.com/D-Programming-Language/dmd/pull/1560
March 15, 2014
On 3/14/14, Jakob Ovrum <jakobovrum@gmail.com> wrote:
> Back in 2012, invariants were misguidedly made const by default without going through any review whatsoever, breaking a ton of code in the process[1].

How about a compromise based on Andrei's new final(bool) suggestion?
We could implement const(false) to allow overriding the default
behavior of invariants. E.g.:

class C
{
    invariant()  // const-by-default, as usual
    {
    }

    invariant() const(false) // new feature
    {
    }
}

That way existing code stays safe.
March 15, 2014
"Andrej Mitrovic"  wrote in message news:mailman.134.1394883267.23258.digitalmars-d@puremagic.com...

> How about a compromise based on Andrei's new final(bool) suggestion?
> We could implement const(false) to allow overriding the default
> behavior of invariants. E.g.:
>
> class C
> {
>     invariant()  // const-by-default, as usual
>     {
>     }
>
>     invariant() const(false) // new feature
>     {
>     }
> }
>
> That way existing code stays safe.

Yuck.  We can always warn for a while on invariants not explicitly marked as const, if we're worried about breakage.

You should be able to use most of the language without using const, making invariants implicitly const was a bad idea. 

March 15, 2014
On Saturday, 15 March 2014 at 14:46:13 UTC, Daniel Murphy wrote:
> "Andrej Mitrovic"  wrote in message news:mailman.134.1394883267.23258.digitalmars-d@puremagic.com...
>
>> How about a compromise based on Andrei's new final(bool) suggestion?
>> We could implement const(false) to allow overriding the default
>> behavior of invariants. E.g.:
>>
>> class C
>> {
>>    invariant()  // const-by-default, as usual
>>    {
>>    }
>>
>>    invariant() const(false) // new feature
>>    {
>>    }
>> }
>>
>> That way existing code stays safe.
>
> Yuck.  We can always warn for a while on invariants not explicitly marked as const, if we're worried about breakage.
>
> You should be able to use most of the language without using const, making invariants implicitly const was a bad idea.

I agree. Implicit const was only in play for a few releases; a couple of releases of deprecation time should be plenty, especially considering the number of users who have been unable to use invariants in those releases.
March 15, 2014
On 3/15/14, Daniel Murphy <yebbliesnospam@gmail.com> wrote:
> Yuck.  We can always warn for a while on invariants not explicitly marked as
>
> const, if we're worried about breakage.
>
> You should be able to use most of the language without using const, making invariants implicitly const was a bad idea.

Well someone has to convince Dear Leader(s) of this. The first pull[1]
was made 2 years ago (!).

[1] : https://github.com/D-Programming-Language/dmd/pull/1073
March 15, 2014
"Andrej Mitrovic"  wrote in message news:mailman.136.1394896688.23258.digitalmars-d@puremagic.com...

> Well someone has to convince Dear Leader(s) of this. The first pull[1]
> was made 2 years ago (!).
>
> [1] : https://github.com/D-Programming-Language/dmd/pull/1073

Andrei's comment there sounds like he's on board. 

March 15, 2014
On 3/15/14, Daniel Murphy <yebbliesnospam@gmail.com> wrote:
> "Andrej Mitrovic"  wrote in message news:mailman.136.1394896688.23258.digitalmars-d@puremagic.com...
>
>> Well someone has to convince Dear Leader(s) of this. The first pull[1]
>> was made 2 years ago (!).
>>
>> [1] : https://github.com/D-Programming-Language/dmd/pull/1073
>
> Andrei's comment there sounds like he's on board.

Heheh, and Walter was on board with final-by-default!