On 10/18/2014 8:21 AM, Jacob Carlborg wrote:
> On 2014-10-18 07:09, Walter Bright wrote:
>
>> Which means they'll be program bugs, not environmental errors.
>
> Yes, but just because I made a mistake in using a function (hitting an assert)
> doesn't mean I want to have undefined behavior.


As I've said before, tripping an assert by definition means the program has entered an unknown state. I don't believe it is possible for any language to make guarantees beyond that point.

Now, if it is a "known" unknown state, and you want to recover, the solution is straightforward - use enforce(). enforce() offers the guarantees you're asking for.

Using assert() when you mean enforce() is like pulling the fire alarm but not wanting the fire dept. to show up.

On 10/18/2014 9:01 AM, Sean Kelly wrote:
> So you consider the library interface to be user input?

The library designer has to make that decision, not the language.


> What about calls that are used internally but also exposed as part of the library interface?

The library designer has to make a decision about who's job it is to validate the parameters to an interface, and thereby deciding what are input/environmental errors and what are programming bugs.

Avoiding making this decision means the API is underspecified, and we all know how poorly that works.

Consider:

    /******************************
     * foo() does magical things.
     * Parameters:
     *   x   a value that must be greater than 0 and less than 8
     *   y   a positive integer
     * Throws:
     *   Exception if y is negative
     * Returns:
     *   magic value
     */
    int foo(int x, int y)
    in { assert(x > 0 && x < 8); }
    body {
       enforce(y >= 0, "silly rabbit, y should be positive");
       ... return ...;
    }

On Saturday, 18 October 2014 at 17:55:04 UTC, Walter Bright wrote:
> On 10/18/2014 9:01 AM, Sean Kelly wrote:
>> So you consider the library interface to be user input?
>
> The library designer has to make that decision, not the language.
>
>
>> What about calls that are used internally but also exposed as part of the library interface?
>
> The library designer has to make a decision about who's job it is to validate the parameters to an interface, and thereby deciding what are input/environmental errors and what are programming bugs.
>
> Avoiding making this decision means the API is underspecified, and we all know how poorly that works.
>
> Consider:
>
>     /******************************
>      * foo() does magical things.
>      * Parameters:
>      *   x   a value that must be greater than 0 and less than 8
>      *   y   a positive integer
>      * Throws:
>      *   Exception if y is negative
>      * Returns:
>      *   magic value
>      */
>     int foo(int x, int y)
>     in { assert(x > 0 && x < 8); }
>     body {
>        enforce(y >= 0, "silly rabbit, y should be positive");
>        ... return ...;
>     }

Contract Programming. Contract-rider list  all required for this   item api conditions. In that case is a list of exseption handler on client side.
Epic sample of first post, may be like this:
in {rider(except, "this class may trowing io exception, you must defined ...") }

On Saturday, 18 October 2014 at 17:40:43 UTC, Walter Bright wrote:
> On 10/18/2014 8:21 AM, Jacob Carlborg wrote:
>> On 2014-10-18 07:09, Walter Bright wrote:
>>
>>> Which means they'll be program bugs, not environmental errors.
>>
>> Yes, but just because I made a mistake in using a function (hitting an assert)
>> doesn't mean I want to have undefined behavior.
>
>
> As I've said before, tripping an assert by definition means the program has entered an unknown state. I don't believe it is possible for any language to make guarantees beyond that point.

What about using the contracts of a fucntion to optimize? They are mainly asserts, after all.

On 10/18/2014 07:40 PM, Walter Bright wrote:
>
> As I've said before, tripping an assert by definition means the program
> has entered an unknown state. I don't believe it is possible for any
> language to make guarantees beyond that point.

What about the guarantee that your compiler didn't _intentionally_ screw them completely?

On 10/20/2014 1:54 PM, Timon Gehr wrote:
> On 10/18/2014 07:40 PM, Walter Bright wrote:
>>
>> As I've said before, tripping an assert by definition means the program
>> has entered an unknown state. I don't believe it is possible for any
>> language to make guarantees beyond that point.
>
> What about the guarantee that your compiler didn't _intentionally_ screw them
> completely?

What does that mean?

On Monday, 20 October 2014 at 20:36:58 UTC, eles wrote:
> On Saturday, 18 October 2014 at 17:40:43 UTC, Walter Bright wrote:
>> On 10/18/2014 8:21 AM, Jacob Carlborg wrote:
>>> On 2014-10-18 07:09, Walter Bright wrote:
>>>
>>>> Which means they'll be program bugs, not environmental errors.
>>>
>>> Yes, but just because I made a mistake in using a function (hitting an assert)
>>> doesn't mean I want to have undefined behavior.
>>
>>
>> As I've said before, tripping an assert by definition means the program has entered an unknown state. I don't believe it is possible for any language to make guarantees beyond that point.
>
> What about using the contracts of a fucntion to optimize? They are mainly asserts, after all.
        this(errnoEnforce(.fopen(name, stdioOpenmode),
                        text("Cannot open file `", name, "' in mode `",
                                stdioOpenmode, "'")),
                name);
making a couple instances of classes not knowing whether they are necessary at all, the performance did not cry.
And why do you have all type of cars. Is it really you are so good compiler?

> What about using the contracts of a fucntion to optimize? They
Its linking time.
>> is possible for any language to make guarantees beyond that
Of cous no, I will explain later 2-3 hour/ Sorry bisnes
offtop:
	string noexist_file_name = "bag_file_global";
	{writefln("------ begin scope: after");
		auto fobj = File(noexist_file_name);
		scope(failure) writefln("test1.failure");
		scope(exit) writefln("test1.exit");
	}

std.exception.ErrnoException@std\stdio.d(362): Cannot open file `bag_...
---------------
5 line with only a memory addr
0x7C81077 in RegisterWaitForInputIdle
i think you need stoped after first errmsg
see exception.d: in constructor or class ErrnoException : Exception

On Tuesday, 21 October 2014 at 03:25:55 UTC, rst256 wrote:
In this post i forgot make correction machine translation.
I am so sorry!
> On Monday, 20 October 2014 at 20:36:58 UTC, eles wrote:
>> On Saturday, 18 October 2014 at 17:40:43 UTC, Walter Bright wrote:
>>> On 10/18/2014 8:21 AM, Jacob Carlborg wrote:
>>>> On 2014-10-18 07:09, Walter Bright wrote:
>>>>
>>>>> Which means they'll be program bugs, not environmental errors.
>>>>
>>>> Yes, but just because I made a mistake in using a function (hitting an assert)
>>>> doesn't mean I want to have undefined behavior.
>>>
>>>
>>> As I've said before, tripping an assert by definition means the program has entered an unknown state. I don't believe it is possible for any language to make guarantees beyond that point.
>>
>> What about using the contracts of a fucntion to optimize? They are mainly asserts, after all.
>         this(errnoEnforce(.fopen(name, stdioOpenmode),
>                         text("Cannot open file `", name, "' in mode `",
>                                 stdioOpenmode, "'")),
>                 name);
> making a couple instances of classes not knowing whether they are necessary at all, the performance did not cry.
> And why do you have all type of cars. Is it really you are so good compiler?
>
>> What about using the contracts of a fucntion to optimize? They
> Its linking time.
>>> is possible for any language to make guarantees beyond that
> Of cous no, I will explain later 2-3 hour/ Sorry bisnes
> offtop:
> 	string noexist_file_name = "bag_file_global";
> 	{writefln("------ begin scope: after");
> 		auto fobj = File(noexist_file_name);
> 		scope(failure) writefln("test1.failure");
> 		scope(exit) writefln("test1.exit");
> 	}
>
> std.exception.ErrnoException@std\stdio.d(362): Cannot open file `bag_...
> ---------------
> 5 line with only a memory addr
> 0x7C81077 in RegisterWaitForInputIdle
> i think you need stoped after first errmsg
> see exception.d: in constructor or class ErrnoException : Exception

On Tuesday, 21 October 2014 at 03:25:55 UTC, rst256 wrote:
> On Monday, 20 October 2014 at 20:36:58 UTC, eles wrote:
>> On Saturday, 18 October 2014 at 17:40:43 UTC, Walter Bright wrote:
>>> On 10/18/2014 8:21 AM, Jacob Carlborg wrote:
>>>> On 2014-10-18 07:09, Walter Bright wrote:

> Its linking time.

No, it's not. At least if you move them in the generated .di files along with function prototypes. Basically, you would pull more source from .d files into .di files.

On Saturday, 18 October 2014 at 17:40:43 UTC, Walter Bright wrote:
> On 10/18/2014 8:21 AM, Jacob Carlborg wrote:
>> On 2014-10-18 07:09, Walter Bright wrote:
>>
>>> Which means they'll be program bugs, not environmental errors.
>>
>> Yes, but just because I made a mistake in using a function (hitting an assert)
>> doesn't mean I want to have undefined behavior.
>
>
> As I've said before, tripping an assert by definition means the program has entered an unknown state. I don't believe it is possible for any language to make guarantees beyond that point.
>
> Now, if it is a "known" unknown state, and you want to recover, the solution is straightforward - use enforce(). enforce() offers the guarantees you're asking for.
>
> Using assert() when you mean enforce() is like pulling the fire alarm but not wanting the fire dept. to show up.

I agree with you on this. I've only ever used assert() for expressing, "This should never happen." There's a difference between "this might happen if the environment goes wrong," which is like a tire being popped in car, and "this should never happen," which is like a car turning into King Kong and flying away. My most common assert in D is typically assert(x !is null) for demanding that objects are initialised.