Walter Bright:

>> assert(x != NULL);
>>
>> if(x != NULL) {
>>     x->foo = 42;
>>     // ...
>> }
>>...
> Your code is doomed to having problems using assert this way.

That usage of assert is fine. D programs use it that way. (And you are going to break lot of D code if you will change the semantics of D assert).

Bye,
bearophile

On 7/30/2014 9:54 PM, bearophile wrote:
> That usage of assert is fine. D programs use it that way. (And you are going to
> break lot of D code if you will change the semantics of D assert).

No, it will break code that already is broken.

On 7/30/2014 8:09 PM, Tofu Ninja wrote:
> When is the appropriate time to use an assert? If an assert
> should not be used on input, then any thing that can't be
> statically known is considered an input and anything that is
> derived from an input is also an input... so when can we use an
> assert? The only things left it seems are things know at compile
> time and at that point what is the the point of having assert
> when we have static assert...

Asserts are used to verify the logic of your code is correct:

   x = y + y;
   assert(x == 2 * y);

On 7/30/2014 9:51 PM, bearophile wrote:
> Walter Bright:
>> So we're back to assert and assume being the same thing. Ok.
> They aren't, and they shouldn't be, regardless the number of times you say they
> are.

Show me a piece of code with different behavior. Start with the array bounds thing.

Walter Bright:

> Show me a piece of code with different behavior. Start with the array bounds thing.

People have already shown you code that behaves differently with assert and assume. But you have redefined "assert" to mean a mix of assume and assert. So before me answering you have to switch back to use the common definition of assert().

Bye,
bearophile

Walter Bright:

> No, it will break code that already is broken.

I have probably lost the grasp of this part of the discussion. But I don't see what's broken in using assert to verify that a pointer is not null. Do you think that pointer comes from "outside"?

Bye,
bearophile

On 7/30/2014 2:32 PM, Ary Borenszweig wrote:
> So if there's a logic in your program, in release mode it won't crash
> immediately but continue with undefined behaviour.

That's right.


> I can't imagine any case where I would want this in my programs.

Don't use -release, then.

On Thursday, 31 July 2014 at 05:05:33 UTC, Walter Bright wrote:
> On 7/30/2014 8:09 PM, Tofu Ninja wrote:
>> When is the appropriate time to use an assert? If an assert
>> should not be used on input, then any thing that can't be
>> statically known is considered an input and anything that is
>> derived from an input is also an input... so when can we use an
>> assert? The only things left it seems are things know at compile
>> time and at that point what is the the point of having assert
>> when we have static assert...
>
> Asserts are used to verify the logic of your code is correct:
>
>    x = y + y;
>    assert(x == 2 * y);

If x and y are floats and y is nan then that assert will fail.....
That assert is implicitly verifying that the input y is not nan,
that is a misuse of assert by your definition.

Any assert made on a piece of data that is derived from inputs is
verifying some aspect of that input, which is a misuse of assert
according to the current definition. So I still state that
according to current definitions, assert should only be used on
things that are known at compile time. What is the use of that?

On 7/30/2014 10:16 PM, bearophile wrote:
> Walter Bright:
>> Show me a piece of code with different behavior. Start with the array bounds
>> thing.
> People have already shown you code that behaves differently with assert and
> assume.

I'd like to see what you are saying is different in a real example.


> But you have redefined "assert" to mean a mix of assume and assert.

I haven't redefined anything. It's always been that way. It's used that way in C/C++ (see your Microsoft C++ link).


> So before me answering you have to switch back to use the common definition of
> assert().

I'm asking what your notion of what assert and assume are, and how that would affect the array bounds checking example.

On 7/30/2014 10:19 PM, bearophile wrote:
> Walter Bright:
>
>> No, it will break code that already is broken.
>
> I have probably lost the grasp of this part of the discussion. But I don't see
> what's broken in using assert to verify that a pointer is not null. Do you think
> that pointer comes from "outside"?

Daniel wants his code to be in a valid state even if the assert is not true, i.e. he wants it to continue to operate as if the pointer might be null.