On 05-08-2012 11:47, Simen Kjaeraas wrote:
On Sun, 05 Aug 2012 11:36:56 +0200, Jakob Ovrum
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
On 06-08-2012 19:57, deadalnix wrote:
Le 05/08/2012 11:47, Simen Kjaeraas a écrit :
On Sun, 05 Aug 2012 11:36:56 +0200, Jakob Ovrum
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
Le 05/08/2012 11:47, Simen Kjaeraas a écrit :
On Sun, 05 Aug 2012 11:36:56 +0200, Jakob Ovrum
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 t
On Sun, 05 Aug 2012 11:36:56 +0200, Jakob Ovrum
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.
Pleas
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
everythi
On Sat, 04 Aug 2012 16:08:42 +0200, Andrei Alexandrescu
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 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 an
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
"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 ca
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 t
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 i
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 illus
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 t
On Saturday, August 04, 2012 09:06:19 Era Scarecrow wrote:
> As mentioned before, doesn't 'const' _only_ apply to the current
> (this) object and not anything else? Besides the contracts can't
> have lasting side effects that would change logical execution.
> How would changing the current object
On Saturday, 4 August 2012 at 06:53:16 UTC, Mehrdad wrote:
It's worth pointing out the obvious, I.e. that as long as
'const' is physical const instead of logical const (which is
always), invariants and contracts can't be const, because that
would restrict them from calling methods that are logi
It's worth pointing out the obvious, i.e. that as long as 'const'
is physical const instead of logical const (which is always),
invariants and contracts can't be const, because that would
restrict them from calling methods that are logically but not
physically const.
So I think they probably
On Friday, August 03, 2012 12:36:41 H. S. Teoh wrote:
> IMO, if you need to be changing stuff inside invariants, then you're
> using it wrong. Invariants are intended to verify program logic, not to
> do things like altering object state. The point is to be able to compile
> with invariant code tur
Am Fri, 03 Aug 2012 22:40:02 +0200
schrieb "bearophile" :
> Another solution (that doesn't replace the need for the
> prestate!) is ghost fields, that are class instance/struct fields
> usable only inside contracts and that vanish in release mode:
> http://d.puremagic.com/issues/show_bug.cgi?id=
On Friday, 3 August 2012 at 20:48:29 UTC, 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
On 03-08-2012 22:32, Davidson Corry wrote:
On 8/3/2012 1:14 PM, Paulo Pinto wrote:
Personally I feel D's contracts are still a bit off of what Eiffel,
.NET and Ada 2012 offer.
On 8/3/2012 1:01 PM, Alex Rønne Petersen wrote:
So what if, for whatever reason, the invariant needs to track and
On 03-08-2012 22:40, bearophile wrote:
Alex Rønne Petersen:
So what if, for whatever reason, the invariant needs to track and
maintain some state in order to catch some kind of ugly bug?
This is legitimate practical need. I know two or more ways to solve that
problem, one of them is to implem
On 03-08-2012 22:17, Davidson Corry wrote:
On 8/3/2012 12:40 PM, bearophile wrote:
H. S. Teoh:
IMO, if you need to be changing stuff inside invariants, then you're
using it wrong. Invariants are intended to verify program logic, not
to do things like altering object state. The point is to be a
Alex Rønne Petersen:
So what if, for whatever reason, the invariant needs to track
and maintain some state in order to catch some kind of ugly bug?
This is legitimate practical need. I know two or more ways to
solve that problem, one of them is to implement the prestate
(old). That's probabl
On 8/3/2012 1:14 PM, Paulo Pinto wrote:
Personally I feel D's contracts are still a bit off of what Eiffel,
.NET and Ada 2012 offer.
On 8/3/2012 1:01 PM, Alex Rønne Petersen wrote:
So what if, for whatever reason, the invariant needs to track and
maintain some state in order to catch some ki
On 8/3/2012 12:40 PM, bearophile wrote:
H. S. Teoh:
IMO, if you need to be changing stuff inside invariants, then you're
using it wrong. Invariants are intended to verify program logic, not
to do things like altering object state. The point is to be able to
compile with invariant code turned of
On Friday, 3 August 2012 at 19:43:18 UTC, Simen Kjaeraas wrote:
On Fri, 03 Aug 2012 21:36:41 +0200, H. S. Teoh
wrote:
IMO, if you need to be changing stuff inside invariants, then
you're
using it wrong. Invariants are intended to verify program
logic, not to
do things like altering object st
On 03-08-2012 21:36, H. S. Teoh wrote:
On Fri, Aug 03, 2012 at 09:19:22PM +0200, Alex Rønne Petersen wrote:
[...]
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 constru
H. S. Teoh:
IMO, if you need to be changing stuff inside invariants, then
you're using it wrong. Invariants are intended to verify
program logic, not to do things like altering object state. The
point is to be able to compile with invariant code turned off,
and still have the program work exa
On Fri, 03 Aug 2012 21:36:41 +0200, H. S. Teoh
wrote:
IMO, if you need to be changing stuff inside invariants, then you're
using it wrong. Invariants are intended to verify program logic, not to
do things like altering object state. The point is to be able to compile
with invariant code turne
On 03-08-2012 21:19, Alex Rønne Petersen wrote:
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, bu
On Fri, Aug 03, 2012 at 09:19:22PM +0200, Alex Rønne Petersen wrote:
[...]
> 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
[...]
> I beli
On Fri, 03 Aug 2012 21:19:22 +0200, Alex Rønne Petersen
wrote:
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 e
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 thr
33 matches
Mail list logo
