On Saturday, 4 August 2012 at 07:15:50 UTC, Jonathan M Davis wrote:
> The problem is that if the this pointer/reference is const, then you can't call any member functions which aren't const, and you can't call any non-const functions on any member variables, because _they're_ const, because the this pointer/reference is const. And there are plenty of types out there which _can't_ have many of their member functions be const and do what they need to do, because D's const is both physical and transitive (unlike C++'s const). So, it's quite easy to get into a situation, where you can't call much of any functions at all if the this pointer/reference is const even though calling the non-const functions wouldn't actually mutate anything.

 Data-wise I see it both as a problem, and not as a problem. so contracts and invariants and debug statements should have the @safe, pure, and const nature stripped for debugging support.

 I would think it does however during verbose output specifying if an invariant or contract is changing data and that may alter behavior.

Le 03/08/2012 21:19, Alex Rønne Petersen a écrit :
> Hi,
>
> This:
>
> $ cat test.d
> class A
> {
> int i;
>
> invariant()
> {
> i = 42;
> }
> }
>
> Currently doesn't compile:
>
> $ dmd test.d
> test.d(7): Error: can only initialize const member i inside constructor
>
> (Obviously this example is silly, but it's just meant to illustrate the
> point of this thread.)
>
> I believe this behavior is too strict. I don't agree that the language
> should dictate what *my* invariant can and cannot do. Not to mention
> that the standard library is far from const-friendly enough for this
> strictness to be practically reasonable today (I have tons of cast()s in
> my programs today due to this - not cool).
>
> Does anyone else find this behavior too strict?
>

I don't.

Actually, it save from many mistakes. You are always free to cast away const. This is unsafe, but you are in an invariant and aren't supposed to do non const operation. At the end, this is fair.

As usual, a safe behavior is proposed, and ways exists to free yourself from safety. This is Dish.

You mention a good point when saying that a lot of lib isn't const friendly and this is true. The problem don't lie into invariant and constness but here.

Le 03/08/2012 22:41, Alex Rønne Petersen a écrit :
> Further, I had to insert casts that cast away constness in some cases
> because the standard library just isn't const-friendly enough. We need
> to get our priorities straight.
>

Why don't you think this is actually the issue ? (I do).

BTW, const inference could be great to solve that or that problem will arise again and again.

On Saturday, August 04, 2012 10:37:55 deadalnix wrote:
> I don't.
> 
> Actually, it save from many mistakes. You are always free to cast away const. This is unsafe, but you are in an invariant and aren't supposed to do non const operation. At the end, this is fair.

All that would be required to have a const invariant if invariants aren't const by default would be to mark it const. That's how it works with pure (unless invariants are always pure now along with const, in which case, this is how it _worked_ with pure). So, you can have the extra safety if you want it, but as long as invariant is automatically const, you can't safely make in non-const, which is unnecessarily inflexible.

D needs to work well with const, but one of the goals is also to make it so that it's not required if you don't want to or can't use it. Forcing invariants to be const goes against this. But that decision was probably made before the recent decisions on Object and const functions (i.e. that toString, toHash, opCmp, and opEquals will no longer be part of Object, so you'll be able to make them whatever constness you want), and I expect that it'll be reverted as long as it's appropriately pointed out to Walter (though it may require someone else creating a pull request with the actual changes).

- Jonathan M Davis

"Era Scarecrow" , dans le message (digitalmars.D:174206), a écrit :
>   I would think it does however during verbose output specifying
> if an invariant or contract is changing data and that may alter
> behavior.

Signatures in some place should be by default const, pure, nothrow. This is the case for invariant() (if you consider it as a function) [1]. However, it is only possible to have different default than non-const, non-pure, throw, if the langage support a way to remove those default attributes. Maybe this should be included in the langage.

-- 
Christophe

[1] Actually, I would rather have a langage where all functions are by default const (wrt all parameters, except this), pure, nothrow... But it seems D is not that langage and it not going to be.

On 8/4/12 4:45 AM, Jonathan M Davis wrote:
> D needs to work well with const, but one of the goals is also to make it so
> that it's not required if you don't want to or can't use it. Forcing
> invariants to be const goes against this. But that decision was probably made
> before the recent decisions on Object and const functions (i.e. that toString,
> toHash, opCmp, and opEquals will no longer be part of Object, so you'll be
> able to make them whatever constness you want), and I expect that it'll be
> reverted as long as it's appropriately pointed out to Walter (though it may
> require someone else creating a pull request with the actual changes).

My opinion in the matter is that invariants are meant to be gatekeeper code that makes sure things stay sane and bug-free. Such code should have special exemptions, much like the debug statement does. Protecting invariants against their own bugs seems a bit extreme to me.

I think a stance could be taken either way. Const invariants are like the European police; non-const invariants are like US police.


Andrei

On 8/3/2012 1:48 PM, Alex Rønne Petersen wrote:
> The problem here is that making invariants const *now* means that using
> them in conjunction with Phobos code becomes next to impossible. Casting
> away const will become common practice, and that ain't exactly the way
> we want to go. :/

Understood and agreed. Casting away const just to get the thing to compile, rather than correcting the code that throws the const-downcheck, is wasted effort (or worse, since it hides the problem.)

Perhaps make the invariant const-downcheck a compiler warning, with the understanding that it will become a compiler *error* in some future release? Kind of like an automatic "deprecated" for invariants re this issue?

On Sat, 04 Aug 2012 16:08:42 +0200, Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org> wrote:

> I think a stance could be taken either way. Const invariants are like the European police; non-const invariants are like US police.

Funny, my impression of the US/European police is the exact opposite.

-- 
Simen

On Friday, 3 August 2012 at 19:19:24 UTC, Alex Rønne Petersen wrote:
> Does anyone else find this behavior too strict?

Yes. Sounds like yet another case of forcing bitwise const on something that should only be logically const.

Please stop forcing bitwise constancy on everything. Not everything needs to work with immutable, it should be opt-in (which in this case could mean explicitly marking the invariant as const) for any type.

On Sun, 05 Aug 2012 11:36:56 +0200, Jakob Ovrum <jakobovrum@gmail.com> wrote:

> On Friday, 3 August 2012 at 19:19:24 UTC, Alex Rønne Petersen wrote:
>> Does anyone else find this behavior too strict?
>
> Yes. Sounds like yet another case of forcing bitwise const on something that should only be logically const.
>
> Please stop forcing bitwise constancy on everything. Not everything needs to work with immutable, it should be opt-in (which in this case could mean explicitly marking the invariant as const) for any type.

I was about to argue that non-const invariants could not be called when
calling const or immutable member functions, but then it hit me that
those shouldn't be able to influence the state checked by the invariant
anyway.

-- 
Simen