I'd like to sum up my position and intent on all this.

1. I can discern no useful, practical difference between the notions of assume and assert.

2. The compiler can make use of assert expressions to improve optimization, even in -release mode.

3. Use of assert to validate input is utterly wrong and will not be supported. Use such constructs at your own risk.

4. An assert failure is a non-recoverable error. The compiler may assume that execution does not proceed after one is tripped. The language does allow attempts to shut a program down gracefully after one is tripped, but that must not be misconstrued as assuming that the program is in a valid state at that point.

5. assert(0); is equivalent to a halt, and the compiler won't remove it.

6. enforce() is meant to check for input errors (environmental errors are considered input).

7. using enforce() to check for program bugs is utterly wrong. enforce() is a library creation, the core language does not recognize it.

8. @safe is a guarantee of memory safety. It is not a guarantee that a program passes all its assert expressions. -release does not disable @safe.

9. -noboundscheck does disable @safe's array bounds checks, however, the compiler may assume that the array index is within bounds after use, even without the array bounds check.


I am not terribly good at writing formal legalese specifications for this. I welcome PR's to improve the specification along these lines, if you find any Aha! Gotcha! issues in it. Of course, implementation errors for this in DMD should be reported on bugzilla.

On 7/30/14, 3:01 PM, Walter Bright wrote:
> 7. using enforce() to check for program bugs is utterly wrong. enforce()
> is a library creation, the core language does not recognize it.

GAAAAAA!

On 31/07/14 00:01, Walter Bright via Digitalmars-d wrote:
> 3. Use of assert to validate input is utterly wrong and will not be supported.
> Use such constructs at your own risk.
>
> ...
>
> 6. enforce() is meant to check for input errors (environmental errors are
> considered input).
>
> 7. using enforce() to check for program bugs is utterly wrong. enforce() is a
> library creation, the core language does not recognize it.

A question on that.

There are various places in Phobos where enforce() statements are used to validate function input or class constructor parameters.  For example, in std.random.LinearCongruentialEngine, we have:

    void seed(UIntType x0 = 1) @safe pure
    {
        static if (c == 0)
        {
            enforce(x0, "Invalid (zero) seed for "
                    ~ LinearCongruentialEngine.stringof);
        }
        _x = modulus ? (x0 % modulus) : x0;
        popFront();
    }

while in RandomSample we have this method which is called inside the constructor:

    private void initialize(size_t howMany, size_t total)
    {
        _available = total;
        _toSelect = howMany;
        enforce(_toSelect <= _available,
                text("RandomSample: cannot sample ", _toSelect,
                     " items when only ", _available, " are available"));
        static if (hasLength!Range)
        {
            enforce(_available <= _input.length,
                    text("RandomSample: specified ", _available,
                         " items as available when input contains only ",
                         _input.length));
        }
    }

The point is that using these enforce() statements means that these methods cannot be nothrow, which doesn't seem particularly nice if it can be avoided. Now, on the one hand, one could say that, quite obviously, these methods cannot control their input.  But on the other hand, it's reasonable to say that these methods' input can and should never be anything other than 100% controlled by the programmer.

My take is that, for this reason, these should be asserts and not enforce() statements.  What are your thoughts on the matter?

On 7/30/14, 3:39 PM, Joseph Rushton Wakeling via Digitalmars-d wrote:
> On 31/07/14 00:01, Walter Bright via Digitalmars-d wrote:
>> 7. using enforce() to check for program bugs is utterly wrong.
>> enforce() is a
>> library creation, the core language does not recognize it.
>
> A question on that.
>
> There are various places in Phobos where enforce() statements are used
> to validate function input or class constructor parameters.

Yah, Phobos is a bit inconsistent about that. TDPL discusses the matter: if a library is deployed in separation from the program(s) it serves, it may as well handle arguments as "input". That's what e.g. the Windows API is doing - it consistently considers all function arguments "inputs", scrubs them, and returns error codes for all invalid inputs it detects. In contracts, the traditional libc/Unix interface does little checking, even a strlen(NULL) will segfault.

Phobos is somewhere in the middle - sometimes it verifies arguments with enforce(), some other times it just uses assert().


Andrei

On 7/30/14, 7:01 PM, Walter Bright wrote:
> I'd like to sum up my position and intent on all this.
>
> 7. using enforce() to check for program bugs is utterly wrong. enforce()
> is a library creation, the core language does not recognize it.

What do you suggest to use to check program bugs?

On Wed, Jul 30, 2014 at 08:05:35PM -0300, Ary Borenszweig via Digitalmars-d wrote:
> On 7/30/14, 7:01 PM, Walter Bright wrote:
> >I'd like to sum up my position and intent on all this.
> >
> >7. using enforce() to check for program bugs is utterly wrong. enforce()
> >is a library creation, the core language does not recognize it.
> 
> What do you suggest to use to check program bugs?

This is what assert is designed for.

But if you don't want to check ever to be removed, currently you have to write:

	if (!requiredCondition)
		assert(0); // compiler never removes this

which IMO is relatively clear, and the use of assert(0) for forceful termination is consistent with existing practice in D code.


T

-- 
Старый друг лучше новых двух.

Walter Bright <newshound2@digitalmars.com> wrote:
> 2. The compiler can make use of assert expressions to improve optimization, even in -release mode.

I can see the benefits of that, but I consider it very dangerous.

It similar to undefined behavior in C/C++. There the 'assume/assert' is implicit not explicit, but it's still the same effect.

If the assume/assert is hidden somewhere in a function you basically introduce new traps for UB.

Initially I was strong proponent of such optimizations:
(a + a)/2 can be optimized to just a for signed integers, that's nice, the
classic example. This inserts an implicit assume(a < INT_MAX/2).

My opinion suddenly changed when I realized that such assumptions (explicit
or implicit) can also propagate up/backwards and leak into a bigger
context.
A wrong assumption can introduce bugs in seemingly unrelated parts of the
program that would actually be correct on their own.

With relatively 'dumb' compilers, this is not a big problem, but optimizers are more and more clever and will take profit of such assumptions if they can.

Tobi

On Wednesday, 30 July 2014 at 22:58:01 UTC, Andrei Alexandrescu wrote:
> On 7/30/14, 3:39 PM, Joseph Rushton Wakeling via Digitalmars-d wrote:
>> On 31/07/14 00:01, Walter Bright via Digitalmars-d wrote:
>>> 7. using enforce() to check for program bugs is utterly wrong.
>>> enforce() is a
>>> library creation, the core language does not recognize it.
>>
>> A question on that.
>>
>> There are various places in Phobos where enforce() statements are used
>> to validate function input or class constructor parameters.
>
> Yah, Phobos is a bit inconsistent about that. TDPL discusses the matter: if a library is deployed in separation from the program(s) it serves, it may as well handle arguments as "input". That's what e.g. the Windows API is doing - it consistently considers all function arguments "inputs", scrubs them, and returns error codes for all invalid inputs it detects. In contracts, the traditional libc/Unix interface does little checking, even a strlen(NULL) will segfault.
>
> Phobos is somewhere in the middle - sometimes it verifies arguments with enforce(), some other times it just uses assert().

Yeah, we're not entirely consistent with it. However, if it would definitely be a program bug for an argument to not pass a particular condition, then it should be an assertion, and if it's definitely likely to be program input (e.g. this is frequently the case with strings), then exceptions are the appropriate approach. It's the cases where it's not obviously program input that's more debatable. Forcing checks and throwing exceptions incurs overhead, but it can significantly reduce programming bugs, because it doesn't put the onus on the programmer to verify the arguments. Using assertions is more performant but can significantly increase the risk of bugs - particularly when the assertions will all be compiled out when Phobos is compiled into a library unless the function is templated.

I know that Walter favors using assertions everywhere and then providing functions which do the checks so that the programmer can check and then throw if appropriate, but the check isn't forced. Personally, I much prefer being defensive and to default to checking the input and throwing on bad input but to provide a way to avoid the check if you've already validated the input and don't want the cost of the check. For instance, many of the functions in std.datetime throw (particularly constructors), because it's being defensive, but it's on my todo list to add functions to bypass some of the checks (e.g. a function which constructs the type without doing any checks in addition to having the normal constructors). Regardless, I think that using assertions as the go-to solution for validating function arguments is generally going to result in a lot more programming bugs. I'd much prefer to default to being safe but provide backdoors for speed when you need it (which is generally how D does things).

But regardless of which approach you prefer, there are some cases where it's pretty clear whether an assertion or exception should be used, and there are other cases where it's highly debatable - primarily depending on whether you want to treat a function's arguments as user input or rely on the programmer to do all of the necessary validations first.

- Jonathan M Davis

On 7/30/14, 4:51 PM, Tobias Müller wrote:
> With relatively 'dumb' compilers, this is not a big problem, but optimizers
> are more and more clever and will take profit of such assumptions if they
> can.

That's true, and it seems like a growing trend. Relevant threads:

https://groups.google.com/a/isocpp.org/forum/#!topic/std-proposals/9S5jNRW-5wY

http://www.spinics.net/lists/gcchelp/msg41714.html

Recent versions of gcc and clang have become increasingly aggressive about optimizing code by taking advantage of making undefined behavior _really_ undefined. There's been a couple of posts in the news recently that I can't find at the moment.


Andrei

On 7/30/14, 5:29 PM, Andrei Alexandrescu wrote:
> On 7/30/14, 4:51 PM, Tobias Müller wrote:
>> With relatively 'dumb' compilers, this is not a big problem, but
>> optimizers
>> are more and more clever and will take profit of such assumptions if they
>> can.
>
> That's true, and it seems like a growing trend. Relevant threads:
>
> https://groups.google.com/a/isocpp.org/forum/#!topic/std-proposals/9S5jNRW-5wY
>
>
> http://www.spinics.net/lists/gcchelp/msg41714.html
>
> Recent versions of gcc and clang have become increasingly aggressive
> about optimizing code by taking advantage of making undefined behavior
> _really_ undefined. There's been a couple of posts in the news recently
> that I can't find at the moment.

I think I found it: http://www.redfelineninja.org.uk/daniel/?p=307

Andreu