On 7/30/2014 1:45 PM, "Ola Fosheim Grøstad" <ola.fosheim.grostad+dlang@gmail.com>" wrote:
> Can you please read the Hoare article form 1969? This is getting really annoying.

Ironically, your wikipedia entry on Hoare references http://en.wikipedia.org/wiki/Assertion_(computing) which is exactly what D's assert does.

On 07/30/2014 10:39 PM, Walter Bright wrote:
> On 7/30/2014 2:12 AM, bearophile wrote:
>> Info about assume in Microsoft C++:
>> http://msdn.microsoft.com/en-us/library/1b3fsfxw.aspx
>
> Note that document shows how assert

Some random ASSERT macro with custom behaviour. That article shows a few alternatives for an ASSERT macro, one of which is basically what D's assert expression does.

The primitives used are

( (e) || assert(__FILE__, __LINE__))

and

__assume(e);

Because the compiler does not seem know that 'assert' never returns, they shove in an __assume after it.

#define ASSERT(e)    ( ((e) || assert(__FILE__, __LINE__)), __assume(e))

This is an implementation detail.

One can just as well do e.g.:

#ifdef DEBUG
# define ASSERT(e)    ( ((e) || assert(__FILE__, __LINE__) )
#else
# define ASSERT(e)
#endif

#define ASSUME(e) __assume(e)

and this and similar options avoid undefined behaviour in non-DEBUG mode caused on ASSERT, while still having the possibility of giving optimization hints explicitly in the form of ASSUME. In this case, the distinction is important even operationally, and it would be a sane alternative to the current approach. There is no a priori absolute single true way when discussing alternatives, and frankly, this should be obvious.

> is implemented using assume. I.e. they are the same thing.
> ...

Yes, and writeln is obviously the same thing as a hello world program.

> Intriguingly, the __assume(0) behavior is even special cased like D's
> assert(0). ...

It is not special cased at all. It is documented specially, because not everyone seems to be that deep into logic.

On 7/30/2014 2:06 PM, "Ola Fosheim Grøstad" <ola.fosheim.grostad+dlang@gmail.com>" wrote:
> Pretty clear, now huh?

I'm curious if you can find an existing computer language that implements both assume and assert and draws some sort of semantic distinction between them.

bearophile's Microsoft C++ example isn't one of them, as it is nothing more than a workaround for the C Standard requiring assert to be a macro.

On 7/30/2014 1:56 PM, David Bregman wrote:
> Can you please address the fact that assume is not @safe?
> How do you propose to
> preserve memory safety in release mode if you remove runtime checks for asserts
> but still assume the condition for codegen?

D's @safe feature is not semantically tied to D's assert expressions.

On 07/30/2014 11:15 PM, Walter Bright wrote:
> On 7/30/2014 1:45 PM, "Ola Fosheim Grøstad"
> <ola.fosheim.grostad+dlang@gmail.com>" wrote:
>> Can you please read the Hoare article form 1969? This is getting
>> really annoying.
>
> Ironically, your wikipedia entry on Hoare references
> http://en.wikipedia.org/wiki/Assertion_(computing) which is exactly what
> D's assert does.
>

Did you read the article?

http://en.wikipedia.org/wiki/Assertion_%28computing%29#Disabling_assertions

'[...] disabling assertion checking can mean that a program that would have aborted will continue to run. This is sometimes preferable.'

This is not what DMD does in -release where assertions are 'disabled'. It follows a diametrally opposite philosophy.

On 7/30/14, 5:47 PM, Walter Bright wrote:
> On 7/30/2014 7:36 AM, Ary Borenszweig wrote:
>> Now, if you compile in release mode, according to Walter, all the
>> "asserts" are
>> gone (which, as a side note, is something I don't like: in every case
>> it should
>> throw an AssertError). So the question is: can the compiler still
>> replace that
>> writeln call?
>
> Yes.
>

So if there's a logic in your program, in release mode it won't crash immediately but continue with undefined behaviour.

I can't imagine any case where I would want this in my programs. I think I would always use enforce and never assert.

On 07/30/2014 11:28 PM, Walter Bright wrote:
> On 7/30/2014 1:56 PM, David Bregman wrote:
>> Can you please address the fact that assume is not @safe?
>> How do you propose to
>> preserve memory safety in release mode if you remove runtime checks
>> for asserts
>> but still assume the condition for codegen?
>
> D's @safe feature is not semantically tied to D's assert expressions.

He understands that and notes that this contradicts the promise of @safe.

On 7/30/2014 2:21 PM, Timon Gehr wrote:
> Because the compiler does not seem know that 'assert' never returns, they shove
> in an __assume after it.

The critical bit of misunderstanding here is the C standard *requires* that assert be implemented as a macro, and that NDEBUG will totally disable it. Microsoft needed to add a builtin feature so that the correct assert semantics can be reliably obtained by the optimizer.

It's a mistake to infer from that that assert and assume are different.

On 7/30/2014 2:34 PM, Timon Gehr wrote:
> He understands that and notes that this contradicts the promise of @safe.

No, it does not. @safe never promises that "all your asserts are correct".

@safe's promise is one of memory safety, not a promise of program correctness.

On 07/30/2014 10:55 PM, Andrei Alexandrescu wrote:
> On 7/30/14, 11:31 AM, Timon Gehr wrote:
>> On 07/30/2014 07:56 PM, Andrei Alexandrescu wrote:
>>> On 7/30/14, 9:31 AM, Timon Gehr wrote:
>>>> 'lazy', which denotes pass by name instead of pass by need.
>>>
>>> It's not pass by name.
>>> ...
>>
>> How so? Is it about failure to allocate a closure?
>
> void fun(lazy int a) { ... }
> int x = 42;
> fun(x + 2);
>
> "x + 2" doesn't have a name.
> ...

You might just have been fooled by the name of a concept.

http://en.wikipedia.org/wiki/Evaluation_strategy#Call_by_name


>>> Consider this: after considerable effort you are failing to explain your
>>> case for "assume" to the language creators.
>>
>> I think there was no such case (yet), only an unsuccessful attempt to
>> clear up a misunderstanding based on terminology.
>
> My perception is you were arguing for a very subtle distinction,

My perception is different. Why is this distinction so subtle?

> one that would hardly deserve a language feature.
> ...

version(assert) is a slight generalisation of such a language feature and it is already there. I already noted how the distinction can be implemented approximately in current D, in fact I think this was my first action in this thread.

version(assert) assert(...); // assert without effects on -release code generation.

This then runs into the 'funny naming' issue etc., but this would be going in circles.