View mode: basic / threaded / horizontal-split · Log in · Help
August 04, 2012
Re: Let's not make invariants const
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.
August 04, 2012
Re: Let's not make invariants const
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.
August 04, 2012
Re: Let's not make invariants const
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.
August 04, 2012
Re: Let's not make invariants const
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
August 04, 2012
Re: Let's not make invariants const
"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.
August 04, 2012
Re: Let's not make invariants const
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
August 05, 2012
Re: Let's not make invariants const
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?
August 05, 2012
Re: Let's not make invariants const
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
August 05, 2012
Re: Let's not make invariants const
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.
August 05, 2012
Re: Let's not make invariants const
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
1 2 3 4
Top | Discussion index | About this forum | D home