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
>
> We're not writing code in `English`, but in `D`. That is a fact. :)
> The english definition of 'assert' is *completely irrelevant*.
> Really.
>
> artur

To expand on this: An army of programmers doing real work has in the past encountered this question of what 'assert' should mean in a programming language. For my my codebase decades ago parted ways with C 'assert'; it has its own which has many more features. And so the 'assume' that C's assert may or may not have had in release builds is merely a curiosity,from the POV of this codebase. The English meaning even more so.
Experience with huge codebases trumps the opinion of standards or dictionaries.
But of course I still would like the language to steer newcomers away from such expensive missteps.

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 someone who spends more time developing code with the compiler to spend at least a little effort reading the two lines of documentation for -release and understanding that it disables the runtime assert checks.

+1

I've the same reasoning every time I see big threads about installers: I simply go with the zips for every platform I use D on.

---
Paolo

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
>>> confusion and
>>> passionate debate.
>>
>> I would expect someone who spends more time developing code with the
>> compiler to spend at least a little effort reading the two lines of
>> documentation for -release and understanding that it disables the
>> runtime assert checks.
>
> +1
>
> I've the same reasoning every time I see big threads about installers: I
> simply go with the zips for every platform I use D on.
>
> ---
> Paolo

1. Note that the information about -release given in the above post is misleading. The new -release assigns undefined behaviour to failing assertions.

2. What has this thread to do with installers vs. zips?

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_(len>0);
>>        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 dereference the pointer because it may be e.g. just past the end of the array. Has this been submitted as a bug?

Dereferencing a pointer shouldn't be disallowed -- it would make @safe
almost unusable when dealing with structs. As long as it's impossible
to obtain an invalid pointer (or one with a longer lifetime than the
object it points to) _within_ @safe, it is, well, safe.
Dereferencing a null ptr is an error, but it's not a memory safety
violation.

[Before somebody claims that this means that the assume-based
 transformation of the above function isn't a problem -- this is just
 the a simple example; I didn't want to clutter it up with a @trusted
 helper that would handle the data access. The bounds check would be
 optimized away in that case too.]

artur

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 start to make use of asserts. It's going to cause no end of
>>>> confusion and
>>>> passionate debate.
>>>
>>> I would expect someone who spends more time developing code with the
>>> compiler to spend at least a little effort reading the two lines of
>>> documentation for -release and understanding that it disables the
>>> runtime assert checks.
>>
>> +1
>>
>> I've the same reasoning every time I see big threads about installers: I
>> simply go with the zips for every platform I use D on.
>>
>> ---
>> Paolo
>
> 1. Note that the information about -release given in the above post is misleading. The new -release assigns undefined behaviour to failing assertions.
>
> 2. What has this thread to do with installers vs. zips?

Simple answer: also if I agree with Walter that the documentation can be improved, the consequence of the -release switch over the code base is crystal clear, it's no more that what it is written in the documentation.

We can passionately discuss on the philosophy of undefined behaviour, about the semantic meaning of the word 'assert', about using it for give the compiler hints about possible optimisations, and so on, but the discussion about renaming flags name does not passionate me, like discussions about simplifying the download expand a zip.

---
Paolo

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_(len>0);
>>        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 dereference the pointer because it may be e.g. just past the end
> of the array. Has this been submitted as a bug? -- Andrei
>

There's more than one way to think about it. We could disable all pointer dereferences, but another way is to fall back on the presumption that arguments to @safe functions must themselves be valid.

I.e. is this @safe:

   &array[length]

? How could a pointer past the end be created in @safe code?

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 programs could not reasonably have such proofs, I think the two
> concepts are orthogonal. I'd rename that to a "prove" statement and not an
> "assert" because assert has nothing to do with checking and conflating the two
> has caused confusion.

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.

If other languages use assert to mean "the compiler must prove this to be true" then that's fine for those languages, but it isn't what D's assert is, or can ever be.

I.e. I agree with you.

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 just ban "-release".

Keep in mind, that under the current implementation, removing asserts also removes the bug checking that the asserts presumably were inserted for. If the asserts don't hold true, the program has undetected bugs in it, it is in an unknown and invalid state, and the ability to predict what it will do next is gone.

I.e. you should already have banned use of "-release".

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. I don't have a solution at the moment, but will be thinking about it.