On Tuesday, 23 May 2017 at 08:41:12 UTC, Ola Fosheim Grøstad
wrote:
But in C++/D etc "predicate" usually is just used to refer to a
boolean pure function in the language. Which is reasonable
since there is no support for propositional or predicate logic.
A D assert is only evaluated when we
Just clearing up an old post that bugs me:
On Friday, 1 August 2014 at 10:24:26 UTC, Ola Fosheim Grøstad
wrote:
An assert does not take a predicate.
That was true, as far as D asserts go... but this is also
confusing since "predicate" and "assert" can mean different
things in different
On 2014-08-03 19:59, Artur Skawina via Digitalmars-d wrote:
No; the advantage of using these magic UDA is that they don't need
to be vendor-specific. IOW one can define inline as the GDC magic
attribute, or nothing. Maybe even some other compiler can support it.
And the source code remains
On Sunday, 3 August 2014 at 21:36:44 UTC, Timon Gehr wrote:
Again, in other cases, the -release program will operate as
expected.
If I've grasped your point in the previous reply, yes, maybe.
...
Ok. This was Johannes' point.
Taken, thanks for the explanation: I agree that you both that
On Saturday, 2 August 2014 at 20:04:32 UTC, Johannes Pfau wrote:
Am Sat, 02 Aug 2014 12:19:41 -0700
schrieb Walter Bright newshou...@digitalmars.com:
On 8/2/2014 6:20 AM, Artur Skawina via Digitalmars-d wrote:
The bug was _introduced_ by the assert, the code was 100%
correct.
Asserts are
On Saturday, 2 August 2014 at 22:00:27 UTC, Andrew Godfrey wrote:
On Saturday, 2 August 2014 at 21:36:11 UTC, Tobias Pankrath
wrote:
On Saturday, 2 August 2014 at 21:25:40 UTC, Ola Fosheim
Grøstad wrote:
On Saturday, 2 August 2014 at 20:27:09 UTC, Andrei
Alexandrescu wrote:
Hmmm... code that
On Sunday, 3 August 2014 at 04:29:28 UTC, Kapps wrote:
On Saturday, 2 August 2014 at 19:10:51 UTC, Walter Bright wrote:
On 8/2/2014 4:12 AM, Artur Skawina via Digitalmars-d wrote:
More importantly, it's a huge security flaw. Not all bugs are
equal; an assertion being false means a bug
On 08/03/14 06:29, Kapps via Digitalmars-d wrote:
Not all bugs are equal; an assertion being false means a bug exists, but
optimizing based off of this allows much more severe bugs to exist.
Yes.
Giving a new meaning to `assert` would also affect how it's used.
Asserts would be used not only
On 08/02/2014 11:36 PM, Tobias Pankrath wrote:
On Saturday, 2 August 2014 at 21:25:40 UTC, Ola Fosheim Grøstad wrote:
On Saturday, 2 August 2014 at 20:27:09 UTC, Andrei Alexandrescu wrote:
Hmmm... code that fails assertions is hardly working. -- Andrei
It is not the code that fails the
On 08/03/2014 11:15 AM, Paolo Invernizzi wrote:
because every few milliseconds an assert is triggered
Right, and software does not have security holes because otherwise they
would obviously be exploited every few milliseconds during in-house testing.
the colleague reading the sources is
On Sunday, 3 August 2014 at 10:49:39 UTC, Timon Gehr wrote:
On 08/03/2014 11:15 AM, Paolo Invernizzi wrote:
because every few milliseconds an assert is triggered
Right, and software does not have security holes because
otherwise they would obviously be exploited every few
milliseconds
On 08/03/2014 03:01 PM, Paolo Invernizzi wrote:
On Sunday, 3 August 2014 at 10:49:39 UTC, Timon Gehr wrote:
On 08/03/2014 11:15 AM, Paolo Invernizzi wrote:
because every few milliseconds an assert is triggered
Right, and software does not have security holes because otherwise
they would
On Sunday, 3 August 2014 at 14:10:29 UTC, Timon Gehr wrote:
On 08/03/2014 03:01 PM, Paolo Invernizzi wrote:
On Sunday, 3 August 2014 at 10:49:39 UTC, Timon Gehr wrote:
On 08/03/2014 11:15 AM, Paolo Invernizzi wrote:
because every few milliseconds an assert is triggered
Right, and software
On 8/2/2014 1:06 PM, Artur Skawina via Digitalmars-d wrote:
There's nothing wrong with `assume`, it's very useful for optimizations.
But it's too dangerous to tack `assume` onto `assert`. If they are kept
separate then it's at least possible to carefully audit every 'assume'.
People *will* use
On 2 August 2014 14:54, Artur Skawina via Digitalmars-d
digitalmars-d@puremagic.com wrote:
+
+enum noinline = attribute(noinline);
+enum inline = attribute(forceinline);
+enum flatten = attribute(flatten);
But I'm not sure if exposing `attribute` like that would be
a good idea (until now I
On 8/2/2014 1:23 PM, Andrei Alexandrescu wrote:
Assume we choose that, there's still murky ground:
@system fun(int[] p) {
gun(p.ptr + p.length);
}
@safe gun(int* p) {
if (p) *p = 42;
}
This passes semantic checking but is unsafe and unsafety is in the @safe
code. Well, that's fine, we
On 8/3/14, 8:10 AM, Walter Bright wrote:
On 8/2/2014 1:23 PM, Andrei Alexandrescu wrote:
Assume we choose that, there's still murky ground:
@system fun(int[] p) {
gun(p.ptr + p.length);
}
@safe gun(int* p) {
if (p) *p = 42;
}
This passes semantic checking but is unsafe and unsafety
On Sunday, 3 August 2014 at 15:06:56 UTC, Walter Bright wrote:
On 8/2/2014 1:06 PM, Artur Skawina via Digitalmars-d wrote:
There's nothing wrong with `assume`, it's very useful for
optimizations.
But it's too dangerous to tack `assume` onto `assert`. If they
are kept
separate then it's at
On Sunday, 3 August 2014 at 15:16:31 UTC, Andrei Alexandrescu
wrote:
On 8/3/14, 8:10 AM, Walter Bright wrote:
We could establish a rule for @safe that function arguments
that are
pointers must be pointers to valid memory, not past the end.
I think that's a good stance. -- Andrei
Agreed,
On 08/03/2014 05:00 PM, Paolo Invernizzi wrote:
On Sunday, 3 August 2014 at 14:10:29 UTC, Timon Gehr wrote:
On 08/03/2014 03:01 PM, Paolo Invernizzi wrote:
On Sunday, 3 August 2014 at 10:49:39 UTC, Timon Gehr wrote:
On 08/03/2014 11:15 AM, Paolo Invernizzi wrote:
because every few
On 08/03/14 17:06, Walter Bright via Digitalmars-d wrote:
On 8/2/2014 1:06 PM, Artur Skawina via Digitalmars-d wrote:
There's nothing wrong with `assume`, it's very useful for optimizations.
But it's too dangerous to tack `assume` onto `assert`. If they are kept
separate then it's at least
On 08/03/14 17:14, Iain Buclaw via Digitalmars-d wrote:
On 2 August 2014 14:54, Artur Skawina via Digitalmars-d
But I'm not sure if exposing `attribute` like that would be
a good idea (until now I was always using a static import, so
name clashes were not a problem); I'd probably rename it to
On Saturday, 2 August 2014 at 21:36:11 UTC, Tobias Pankrath wrote:
Don't you agree, that a program that throws AssertError in non
-release* build is broken?
* this is not the opposite of debug
Let's go to the definitions:
Total correctness:
The program can be proved to always terminate
On Sunday, 3 August 2014 at 16:29:18 UTC, Timon Gehr wrote:
On 08/03/2014 05:00 PM, Paolo Invernizzi wrote:
On Sunday, 3 August 2014 at 14:10:29 UTC, Timon Gehr wrote:
On 08/03/2014 03:01 PM, Paolo Invernizzi wrote:
On Sunday, 3 August 2014 at 10:49:39 UTC, Timon Gehr wrote:
On 08/03/2014
On 08/03/2014 11:03 PM, Paolo Invernizzi wrote:
...
But most yes: to me, an undefined behaviour is the situation where I've
developed the code for having 'a' in one place, and I have 'b'. If this
is not, literally undefined behaviour, I donno how I should name it.
...
You could name it a
On 08/02/2014 05:34 AM, Andrew Godfrey wrote:
Suppose I call some logging function which has a faulty assertion in it.
What about Walter's position prevents that assertion's effects from
escaping the logging function and infecting my code?
Nothing. Undefined behaviour is completely
On Saturday, 2 August 2014 at 05:07:58 UTC, Chris Cain wrote:
Actually, I'm going to clarify this: Your assertion is *not*
the promise. Your assertion is simply a statement of fact
(note, that does not mean it's a fact, as that appears to be a
point of confusion: a statement of fact is simply
On Saturday, 2 August 2014 at 05:32:43 UTC, Timon Gehr wrote:
Well, if there is no proof of something, how can I claim it can
be proven? In fact, in my past life, when somebody told me
something like '...and actually one _can prove_ that any
non-planar graph contains either a K_5 or a K_{3,3}
On Saturday, 2 August 2014 at 06:09:42 UTC, Chris Cain wrote:
Sure. A bit of a different flavor, but essentially the same.
Incorrect statements make incorrect program behavior (in the
case of assert, I think understanding the real meaning behind
it will make it far easier to reason about ...
On Saturday, 2 August 2014 at 05:59:14 UTC, Timon Gehr wrote:
On 08/02/2014 05:34 AM, Andrew Godfrey wrote:
Suppose I call some logging function which has a faulty
assertion in it.
What about Walter's position prevents that assertion's effects
from
escaping the logging function and infecting
On 08/02/2014 08:40 AM, Andrew Godfrey wrote:
So even if the assertion is incorrect and the code is correct, the
caller's correctness can be compromised?
Yes. The reasoning is that if the assertion is incorrect, the program is
fundamentally broken, it enters an invalid state and hence it is
On 08/02/2014 08:09 AM, Chris Cain wrote:
On Saturday, 2 August 2014 at 05:32:43 UTC, Timon Gehr wrote:
Well, if there is no proof of something, how can I claim it can be
proven? In fact, in my past life, when somebody told me something like
'...and actually one _can prove_ that any non-planar
On Saturday, 2 August 2014 at 06:08:43 UTC, Tofu Ninja wrote:
On Saturday, 2 August 2014 at 05:07:58 UTC, Chris Cain wrote:
Actually, I'm going to clarify this: Your assertion is *not*
the promise. Your assertion is simply a statement of fact
(note, that does not mean it's a fact, as that
On Saturday, 2 August 2014 at 06:36:00 UTC, Timon Gehr wrote:
http://en.wikipedia.org/wiki/Falsifiability
^^ See?
A statement is called falsifiable if it is possible to
conceive an observation or an argument which proves the
statement in question to be false.
If we have proven the
On Saturday, 2 August 2014 at 07:23:07 UTC, Timon Gehr wrote:
Thanks for having been a reasonable discussion partner.
Same to you. Have a good evening :)
On 08/02/2014 09:00 AM, Chris Cain wrote:
On Saturday, 2 August 2014 at 06:36:00 UTC, Timon Gehr wrote:
http://en.wikipedia.org/wiki/Falsifiability
^^ See?
A statement is called falsifiable if it is possible to conceive an
observation or an argument which proves the statement in question to
On Saturday, 2 August 2014 at 06:35:33 UTC, Chris Cain wrote:
Well, you can disagree but it doesn't change the fact that what
I meant and what you're saying are two different things. With
Yes I disagreed with you... so yes I am saying something
different. What else is disagreement
On Saturday, 2 August 2014 at 07:36:34 UTC, Tofu Ninja wrote:
On Saturday, 2 August 2014 at 06:35:33 UTC, Chris Cain wrote:
Well, you can disagree but it doesn't change the fact that
what I meant and what you're saying are two different things.
With
Yes I disagreed with you... so yes I
On Saturday, 2 August 2014 at 07:36:34 UTC, Tofu Ninja wrote:
...
Look, this is the point I'm trying to make. Given the English
definition of assert (Just accept the definition, I'm tired:
statement of fact or belief confidently and forcefully), I
claim that it makes sense that a compiler
On 08/02/14 11:36, Chris Cain via Digitalmars-d wrote:
On Saturday, 2 August 2014 at 07:36:34 UTC, Tofu Ninja wrote:
...
Look, this is the point I'm trying to make. Given the English definition of
assert
We're not writing code in `English`, but in `D`. That is a fact. :)
The english
On Saturday, 2 August 2014 at 05:07:58 UTC, Chris Cain wrote:
On Saturday, 2 August 2014 at 04:40:53 UTC, Tofu Ninja wrote:
His claim is that an assertion is a claim by the person
asserting. That claim has not been proven to be true or false.
Meaning that as a claim, the compiler can't do
On Saturday, 2 August 2014 at 05:07:58 UTC, Chris Cain wrote:
Thus when you assert something is true and the compiler can't
immediately disprove you, it must follow what you say.
The compiler can be much better about proving things about a
program than programmers probably are, especially if
On 08/02/14 05:34, Andrew Godfrey via Digitalmars-d wrote:
Suppose I call some logging function which has a faulty assertion in it. What
about Walter's position prevents that assertion's effects from escaping the
logging function and infecting my code?
Nothing. Walter _wants_ the assumptions
On Saturday, 2 August 2014 at 11:12:42 UTC, Artur Skawina via
Digitalmars-d wrote:
_`assume` is extremely dangerous_.
You sure can come up with an example where -release (and only
with release the problem exists) results in equally dangerous
behaviour by overwriting memory due to disabled
On 08/02/14 14:12, Tobias Pankrath via Digitalmars-d wrote:
On Saturday, 2 August 2014 at 11:12:42 UTC, Artur Skawina via Digitalmars-d
wrote:
_`assume` is extremely dangerous_.
You sure can come up with an example where -release (and only with release
the problem exists) results in
On Saturday, 2 August 2014 at 12:44:26 UTC, Artur Skawina via
Digitalmars-d wrote:
--
Keep in mind that the `assert` can be elsewhere, in a different
function and/or module, and can even be written in a different
language. The
On 08/02/14 14:54, Tobias Pankrath via Digitalmars-d wrote:
I agree that this might hide bugs, but I don't agree that the additional
trouble is bigger than the additional payoffs.
The bug was _introduced_ by the assert, the code was 100% correct.
Imagine working on a project with dozen+
On 2 August 2014 12:12, Artur Skawina via Digitalmars-d
digitalmars-d@puremagic.com wrote:
-
static import gcc.attribute;
enum inline = gcc.attribute.attribute(forceinline);
@inline void assert_()(bool c) {
When I
On Saturday, 2 August 2014 at 13:21:07 UTC, Artur Skawina via
Digitalmars-d wrote:
On 08/02/14 14:54, Tobias Pankrath via Digitalmars-d wrote:
I agree that this might hide bugs, but I don't agree that the
additional trouble is bigger than the additional payoffs.
The bug was _introduced_ by
On 08/02/14 15:24, Iain Buclaw via Digitalmars-d wrote:
On 2 August 2014 12:12, Artur Skawina via Digitalmars-d
digitalmars-d@puremagic.com wrote:
-
static import gcc.attribute;
enum inline =
On 08/02/14 15:32, Tobias Pankrath via Digitalmars-d wrote:
On Saturday, 2 August 2014 at 13:21:07 UTC, Artur Skawina via Digitalmars-d
wrote:
On 08/02/14 14:54, Tobias Pankrath via Digitalmars-d wrote:
If there is a wrong assert in the code, it's not perfectly fine.
The code is perfectly
On Saturday, 2 August 2014 at 03:07:25 UTC, Tofu Ninja wrote:
D3 anyone? :)
If assert() is turned into assume() then D will go down as
the buggiest compiler in history. No point in continuing with D*
then.
Then again, there are plenty of other letters. E, F, G, H…
On 8/2/14, 5:44 AM, Artur Skawina via Digitalmars-d wrote:
auto fx(ubyte* p, size_t len) @safe {
assert_(len0);
if (len=1)
return p[0];
return -1;
}
As an aside I think it's a bug that this function passes @safe. It
should not be able to safely
On 2 August 2014 14:54, Artur Skawina via Digitalmars-d
digitalmars-d@puremagic.com wrote:
On 08/02/14 15:24, Iain Buclaw via Digitalmars-d wrote:
On 2 August 2014 12:12, Artur Skawina via Digitalmars-d
digitalmars-d@puremagic.com wrote:
On 08/02/2014 05:08 PM, Andrei Alexandrescu wrote:
On 8/2/14, 5:44 AM, Artur Skawina via Digitalmars-d wrote:
auto fx(ubyte* p, size_t len) @safe {
assert_(len0);
if (len=1)
return p[0];
return -1;
}
As an aside I think it's a bug that this function
On Saturday, 2 August 2014 at 10:21:44 UTC, Artur Skawina via
Digitalmars-d wrote:
On 08/02/14 11:36, Chris Cain via Digitalmars-d wrote:
On Saturday, 2 August 2014 at 07:36:34 UTC, Tofu Ninja wrote:
...
Look, this is the point I'm trying to make. Given the English
definition of assert
On Friday, 1 August 2014 at 18:33:34 UTC, Walter Bright wrote:
On 8/1/2014 4:53 AM, Don wrote:
I think very strongly that we should rename the -release
switch, especially if
we do start to make use of asserts. It's going to cause no end
of confusion and
passionate debate.
I would expect
On 08/02/2014 06:03 PM, Paolo Invernizzi wrote:
On Friday, 1 August 2014 at 18:33:34 UTC, Walter Bright wrote:
On 8/1/2014 4:53 AM, Don wrote:
I think very strongly that we should rename the -release switch,
especially if
we do start to make use of asserts. It's going to cause no end of
On 08/02/14 17:08, Andrei Alexandrescu via Digitalmars-d wrote:
On 8/2/14, 5:44 AM, Artur Skawina via Digitalmars-d wrote:
auto fx(ubyte* p, size_t len) @safe {
assert_(len0);
if (len=1)
return p[0];
return -1;
}
As an aside I think it's a bug that
On Saturday, 2 August 2014 at 16:22:07 UTC, Timon Gehr wrote:
On 08/02/2014 06:03 PM, Paolo Invernizzi wrote:
On Friday, 1 August 2014 at 18:33:34 UTC, Walter Bright wrote:
On 8/1/2014 4:53 AM, Don wrote:
I think very strongly that we should rename the -release
switch,
especially if
we do
On 8/2/2014 8:08 AM, Andrei Alexandrescu wrote:
On 8/2/14, 5:44 AM, Artur Skawina via Digitalmars-d wrote:
auto fx(ubyte* p, size_t len) @safe {
assert_(len0);
if (len=1)
return p[0];
return -1;
}
As an aside I think it's a bug that this function passes
On 8/2/2014 12:00 AM, Chris Cain wrote:
It is not so clear where to draw the boundaries. In some languages you may
need to prove the assertion true in order for it to pass the type checker.
That would be a cool construct as well, don't get me wrong. But considering the
vast majority of
On 8/2/2014 4:12 AM, Artur Skawina via Digitalmars-d wrote:
_`assume` is extremely dangerous_. Redefining `assert` to include `assume`
would result in D's `assert` being banned from the whole code base, if 'D'
even would be consider a 'sane' enough language to use...
More simply, you could
On 8/2/2014 6:20 AM, Artur Skawina via Digitalmars-d wrote:
The bug was _introduced_ by the assert, the code was 100% correct.
Asserts are part of the code, and writing incorrect asserts is writing buggy
code.
On 8/2/2014 7:11 AM, Artur Skawina via Digitalmars-d wrote:
@safe was supposed to protect from that.
Just to be pedantic, @safe is supposed to provide memory safety, not protection
against all UB.
Your concern about assert optimizations possibly removing some @safe bounds
checks is valid.
On 08/02/2014 09:01 PM, Walter Bright wrote:
I think at this point it is quite clear that D's assert is about the
programmer saying this expression evaluates to true or it's a
programming bug.
That was already obvious to most before the discussion started.
In any case, the way you'd need to
Am Sat, 02 Aug 2014 12:19:41 -0700
schrieb Walter Bright newshou...@digitalmars.com:
On 8/2/2014 6:20 AM, Artur Skawina via Digitalmars-d wrote:
The bug was _introduced_ by the assert, the code was 100% correct.
Asserts are part of the code, and writing incorrect asserts is
writing buggy
On 08/02/14 21:19, Walter Bright via Digitalmars-d wrote:
On 8/2/2014 6:20 AM, Artur Skawina via Digitalmars-d wrote:
The bug was _introduced_ by the assert, the code was 100% correct.
Asserts are part of the code, and writing incorrect asserts is writing buggy
code.
This was about
On 8/2/14, 11:55 AM, Walter Bright wrote:
On 8/2/2014 8:08 AM, Andrei Alexandrescu wrote:
On 8/2/14, 5:44 AM, Artur Skawina via Digitalmars-d wrote:
auto fx(ubyte* p, size_t len) @safe {
assert_(len0);
if (len=1)
return p[0];
return -1;
}
As an aside I
On 8/2/14, 1:02 PM, Johannes Pfau wrote:
I just want to point out that nobody wants to hear 'your code was buggy
anyway' after a compiler update broke working code.
Hmmm... code that fails assertions is hardly working. -- Andrei
On Saturday, 2 August 2014 at 20:27:09 UTC, Andrei Alexandrescu
wrote:
Hmmm... code that fails assertions is hardly working. -- Andrei
It is not the code that fails the assertion, it is the asserted
proposition that has not be satisfied by the axioms in the
program as it has been formulated
On Saturday, 2 August 2014 at 21:25:40 UTC, Ola Fosheim Grøstad
wrote:
On Saturday, 2 August 2014 at 20:27:09 UTC, Andrei Alexandrescu
wrote:
Hmmm... code that fails assertions is hardly working. -- Andrei
It is not the code that fails the assertion, it is the asserted
proposition that has
On Saturday, 2 August 2014 at 21:36:11 UTC, Tobias Pankrath wrote:
On Saturday, 2 August 2014 at 21:25:40 UTC, Ola Fosheim Grøstad
wrote:
On Saturday, 2 August 2014 at 20:27:09 UTC, Andrei
Alexandrescu wrote:
Hmmm... code that fails assertions is hardly working. --
Andrei
It is not the code
Am 02.08.2014 22:02, schrieb Johannes Pfau:
Am Sat, 02 Aug 2014 12:19:41 -0700
schrieb Walter Bright newshou...@digitalmars.com:
On 8/2/2014 6:20 AM, Artur Skawina via Digitalmars-d wrote:
The bug was _introduced_ by the assert, the code was 100% correct.
Asserts are part of the code, and
On Saturday, 2 August 2014 at 20:23:53 UTC, Andrei Alexandrescu
wrote:
@system fun(int[] p) {
gun(p.ptr + p.length);
}
@safe gun(int* p) {
if (p) *p = 42;
}
This passes semantic checking but is unsafe and unsafety is in
the @safe code. Well, that's fine, we might say. The problem is
On Saturday, 2 August 2014 at 19:10:51 UTC, Walter Bright wrote:
On 8/2/2014 4:12 AM, Artur Skawina via Digitalmars-d wrote:
_`assume` is extremely dangerous_. Redefining `assert` to
include `assume`
would result in D's `assert` being banned from the whole code
base, if 'D'
even would be
On Friday, 1 August 2014 at 02:44:51 UTC, Walter Bright wrote:
That entry makes no mention of assert being used as an
optimization hint.
Saying that a predicate is always true means it's available to
the optimizer.
An assert does not say that the predicate is always true. It says
that this
On Friday, 1 August 2014 at 02:46:48 UTC, Walter Bright wrote:
On 7/31/2014 1:36 PM, Tofu Ninja wrote:
On Thursday, 31 July 2014 at 19:12:04 UTC, Walter Bright wrote:
Integers are sortable, period. That is not input.
Ok so sorted ints are not input, what else is not input?
Where can I draw
On Friday, 1 August 2014 at 06:24:29 UTC, Ola Fosheim Grøstad
wrote:
DESIGN BY CONTRACT
BTW, there is an emerging field program synthesis that is based
on Design by contract where the compiler automatically generates
code that takes you from preconditions to postconditions and
verifies it
On Friday, 1 August 2014 at 03:17:06 UTC, Walter Bright wrote:
In fact, the whole reason assert is a core language feature
rather than
a library notion is I was anticipating making use of assert
for
optimization hints.
So why is this not documented?
Frankly, it never occurred to me that it
John Colvin:
This is enough to convince me.
Please don't feed Walter.
Bye,
bearophile
On 7/31/2014 11:24 PM, Ola Fosheim Grøstad
ola.fosheim.grostad+dl...@gmail.com wrote:
On Friday, 1 August 2014 at 02:44:51 UTC, Walter Bright wrote:
That entry makes no mention of assert being used as an optimization hint.
Saying that a predicate is always true means it's available to the
On 8/1/2014 1:31 AM, John Colvin wrote:
Don't want the optimiser to use the information from your asserts when the
asserts are gone?
You can always do:
version(assert) { if (!exp) halt(); }
and in -release mode, the compiler won't assume that exp is true. Or, more
simply, just write your
On 8/1/2014 1:43 AM, bearophile wrote:
John Colvin:
This is enough to convince me.
Please don't feed Walter.
I don't care if you make such remarks about me, but I do care about the level of
discourse in the forum sinking to such levels. Please refrain from such.
On Friday, 1 August 2014 at 03:58:22 UTC, Walter Bright wrote:
If you look at the Wikipedia article,
http://en.wikipedia.org/wiki/Assertion_(software_development)
you'll see a more high level view of what assert is all about,
rather than a worm's eye view the C standard takes. (It even
On Friday, 1 August 2014 at 09:02:36 UTC, Walter Bright wrote:
On 7/31/2014 11:24 PM, Ola Fosheim Grøstad
An assert does not say that the predicate is always true.
Yes, it does. From Meyers' comprehensive tome on the topic
Object-Oriented Software Construction (1997) where he writes:
A
Walter Bright:
I don't care if you make such remarks about me, but I do care
about the level of discourse in the forum sinking to such
levels. Please refrain from such.
Yes sorry, I have lost my temper when you have written Or
perhaps some people are just being argumentative. I can't really
On Friday, 1 August 2014 at 09:02:36 UTC, Walter Bright wrote:
On 7/31/2014 11:24 PM, Ola Fosheim Grøstad
ola.fosheim.grostad+dl...@gmail.com wrote:
On Friday, 1 August 2014 at 02:44:51 UTC, Walter Bright wrote:
That entry makes no mention of assert being used as an
optimization hint.
Saying
On Friday, 1 August 2014 at 10:42:50 UTC, Marc Schütz wrote:
On Friday, 1 August 2014 at 09:02:36 UTC, Walter Bright wrote:
On 7/31/2014 11:24 PM, Ola Fosheim Grøstad
ola.fosheim.grostad+dl...@gmail.com wrote:
On Friday, 1 August 2014 at 02:44:51 UTC, Walter Bright wrote:
That entry makes no
On Friday, 1 August 2014 at 04:51:06 UTC, eles wrote:
assert(0) is a special contract that requires no code for its
verification, as it obviously fails. This is why the compiler
will always make it a halting point, in all builds.
This is wrong. As I have shown over in the other thread, the
On Friday, 1 August 2014 at 09:02:36 UTC, Walter Bright wrote:
On 7/31/2014 11:24 PM, Ola Fosheim Grøstad
ola.fosheim.grostad+dl...@gmail.com wrote:
On Friday, 1 August 2014 at 02:44:51 UTC, Walter Bright wrote:
That entry makes no mention of assert being used as an
optimization hint.
Saying
On Friday, 1 August 2014 at 04:51:06 UTC, eles wrote:
While in Debug mode
Generally decent, but I don't agree that the absence of -release
implies debug mode.
-Wyatt
On Friday, 1 August 2014 at 11:53:28 UTC, Don wrote:
I think very strongly that we should rename the -release
switch, especially if we do start to make use of asserts. It's
going to cause no end of confusion and passionate debate.
Pretty much summary of both threads.
On Friday, 1 August 2014 at 11:53:28 UTC, Don wrote:
The arguments presented by Ola et al mostly seem to be
arguments against the use of the -release switch. Because it is
No, I think I do understand where Walter is coming from now. I
remember some of the incomprehensible lectures I attended
Am 01.08.2014 05:17, schrieb Walter Bright:
Frankly, it never occurred to me that it wasn't obvious. When something
is ASSERTED to be true, then it is available to the optimizer. After
all, that is what optimizers do - rewrite code into a mathematically
equivalent form that is provably the same
Am 01.08.2014 05:27, schrieb Walter Bright:
On 7/31/2014 1:11 PM, Daniel Gibson wrote:
I guess in many cases I'd avoid using assert() in fear of breaking my
defensively written program (like that example from earlier: assert(x
!is null);
if(x) { x.foo = 42; }).
I just hang my head in my hands
On 8/1/14, 1:43 AM, bearophile wrote:
John Colvin:
This is enough to convince me.
Please don't feed Walter.
This is offensive on more than one level. -- Andrei
On 08/01/2014 01:53 PM, Don wrote:
On Friday, 1 August 2014 at 09:02:36 UTC, Walter Bright wrote:
On 7/31/2014 11:24 PM, Ola Fosheim Grøstad
ola.fosheim.grostad+dl...@gmail.com wrote:
On Friday, 1 August 2014 at 02:44:51 UTC, Walter Bright wrote:
That entry makes no mention of assert being
On 08/01/2014 11:02 AM, Walter Bright wrote:
On 7/31/2014 11:24 PM, Ola Fosheim Grøstad
ola.fosheim.grostad+dl...@gmail.com wrote:
On Friday, 1 August 2014 at 02:44:51 UTC, Walter Bright wrote:
That entry makes no mention of assert being used as an optimization
hint.
Saying that a predicate
On 8/1/14, 8:28 AM, Timon Gehr wrote:
On 08/01/2014 01:53 PM, Don wrote:
If you are disabling your asserts, but still believe that they may fail,
that means you're expecting your program to enter undefined behaviour!
Nonsense. This claim is ignoring the current reality of software
1 - 100 of 459 matches
Mail list logo
