On 9 October 2014 17:33, Johannes Pfau via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
> Am Thu, 09 Oct 2014 13:10:34 +0000
> schrieb "Dicebot" <public@dicebot.lv>:
>
>> On Wednesday, 8 October 2014 at 03:20:21 UTC, Walter Bright wrote:
>> >> Can we at least agree that Dicebot's request for having the
>> >> behaviour of
>> >> inadvisable constructs defined such that an implementation
>> >> cannot randomly
>> >> change behaviour and then have the developers close down the
>> >> corresponding
>> >> bugzilla issue because it was the user's fault anyway is not
>> >> unreasonable by
>> >> definition because the system will not reach a perfect state
>> >> anyway, and then
>> >> retire this discussion?
>> >
>> > I've been working with Dicebot behind the scenes to help resolve the particular issues with the code he's responsible for.
>> >
>> > As for D, D cannot offer any guarantees about behavior after a program crash. Nor can any other language.
>>
>> Just wanted to point out that resulting solution (== manually switching many of contracts to exceptions from asserts) to me is an unhappy workaround to deal with overly opinionated language and not actually a solution. I still consider this a problem.
>
> A point which hasn't been discussed yet:
>
> Errors and therefore assert can be used in nothrow functions. This is a pita for compilers because it now can't do certain optimizations. When porting GDC to ARM we started to see problems because of that (can't unwind from nothrow functions on ARM, program just aborts). And now we therefore have to worsen the codegen for nothrow functions because of this.
>
> I think Walter sometimes suggested that it would be valid for a compiler to not unwind Errors at all (in release mode), but simply kill the program and dump a error message. This would finally allow us to optimize nothrow functions.
>

This behaviour was agreed at the bar at DConf.  We'd have to put it in the spec to give it the official stamp of approval though.

Iain.

On Thursday, 9 October 2014 at 16:33:53 UTC, Johannes Pfau wrote:
> I think Walter sometimes suggested that it would be valid for a
> compiler to not unwind Errors at all (in release mode), but simply kill
> the program and dump a error message. This would finally allow us to
> optimize nothrow functions.

I think this is reasonable in general but as long as assert throws Error and assert is encouraged to be used in unittest blocks such implementation would mark compiler as unusable for me.

We may need to have another look at what is truly an Error and what is not before going that path.

On Thursday, 9 October 2014 at 17:31:32 UTC, Dicebot wrote:
> On Thursday, 9 October 2014 at 16:33:53 UTC, Johannes Pfau wrote:
>> I think Walter sometimes suggested that it would be valid for a
>> compiler to not unwind Errors at all (in release mode), but simply kill
>> the program and dump a error message. This would finally allow us to
>> optimize nothrow functions.
>
> I think this is reasonable in general but as long as assert throws Error and assert is encouraged to be used in unittest blocks such implementation would mark compiler as unusable for me.

Can it simply skip unwinding up to the next not-nothrow function? I.e. destructors of objects (and finally/scope(exit)) inside `nothrow` functions will not be executed, but unwinding will continue as normal at the first function up the call stack that supports it?

Would this work for both GDC and LDC? If yes, your unittest framework will probably continue to work as is.

On Thursday, 9 October 2014 at 18:32:55 UTC, Marc Schütz wrote:
> Can it simply skip unwinding up to the next not-nothrow function? I.e. destructors of objects (and finally/scope(exit)) inside `nothrow` functions will not be executed, but unwinding will continue as normal at the first function up the call stack that supports it?
>
> Would this work for both GDC and LDC? If yes, your unittest framework will probably continue to work as is.

Funny that it happens other way around right now with dmd (http://dpaste.dzfl.pl/e685c0c32b0d) :

struct S
{
	string id;	
	
	~this() nothrow
	{
		import core.stdc.stdio;
		printf("%s\n", id.ptr);
	}
}

void foo() nothrow
{
	auto s = S("foo");
	throw new Error("hmm");
}

void main()
{
	auto s = S("main");
	foo();
}

====

foo

object.Error: hmm
----------------
./f57(_Dmain+0x23) [0x4171cf]
./f57(void rt.dmain2._d_run_main(int, char**, extern (C) int function(char[][])*).runAll().void __lambda1()+0x18) [0x417f40]
./f57(void rt.dmain2._d_run_main(int, char**, extern (C) int function(char[][])*).tryExec(scope void delegate())+0x2a) [0x417e9a]
./f57(void rt.dmain2._d_run_main(int, char**, extern (C) int function(char[][])*).runAll()+0x30) [0x417f00]
./f57(void rt.dmain2._d_run_main(int, char**, extern (C) int function(char[][])*).tryExec(scope void delegate())+0x2a) [0x417e9a]
./f57(_d_run_main+0x1a3) [0x417e1b]
./f57(main+0x17) [0x4171f3]
/usr/lib/libc.so.6(__libc_start_main+0xf5) [0x40967a15]

On Wednesday, 8 October 2014 at 07:40:14 UTC, eles wrote:
> Of course it does not increase the probability to get a "tails". Actually, it increases the probability that you'll get "heads" again.

Er, no, unless you assume that repeated flips of the coin in some way deform it so as to bias the outcome.

An extended run of heads might lead you to conclude that the coin is biased, and so increase your _expectation_ that the next flip will also result in a head, but that doesn't alter the actual underlying probability.

On 10 Oct 2014 01:35, "Joseph Rushton Wakeling via Digitalmars-d" < digitalmars-d@puremagic.com> wrote:
>
> On Wednesday, 8 October 2014 at 07:40:14 UTC, eles wrote:
>>
>> Of course it does not increase the probability to get a "tails".
Actually, it increases the probability that you'll get "heads" again.
>
>
> Er, no, unless you assume that repeated flips of the coin in some way
deform it so as to bias the outcome.
>
> An extended run of heads might lead you to conclude that the coin is
biased, and so increase your _expectation_ that the next flip will also result in a head, but that doesn't alter the actual underlying probability.

http://www.wired.com/2012/12/what-does-randomness-look-like/

On 10/8/2014 8:06 AM, Bruno Medeiros wrote:
> (Note: I don't think such dichotomy and compromise *has* to exist in order to
> design a great D and Phobos. But in this discussion I feel the choices and
> vision were heading in a way that would likely harm the development of general
> purpose software in favor of critical systems.)

I definitely believe that Phobos should aid the implementation of critical systems over sloppy ones.

But I don't believe that harms sloppy ones.

Am Wed, 08 Oct 2014 16:30:19 +0100
schrieb Bruno Medeiros <bruno.do.medeiros+dng@gmail.com>:

> I don't think memory-safety is at the core of the issue. Java is memory-safe, yet if you encounter a null pointer exception, you're still not sure if your whole application is now in an unusable state, or if the NPE was just confined to say, the operation the user just tried to do, or some other component of the application. There are no guarantees.

I know a Karaoke software written in .NET, that doesn't check if a list view is empty when trying to select the first element. It results in a popup message about the Exception and you can continue from there.

It is a logic error (aka assertion), but being tailored
towards user interfaces, .NET doesn't kill the app.
Heck, if Mono-D closed down on every NPE I wouldn't be using
it any more. ;)

-- 
Marco

On Friday, 10 October 2014 at 06:28:06 UTC, Iain Buclaw via Digitalmars-d wrote:
> On 10 Oct 2014 01:35, "Joseph Rushton Wakeling via Digitalmars-d" <
> digitalmars-d@puremagic.com> wrote:
>>
>> On Wednesday, 8 October 2014 at 07:40:14 UTC, eles wrote:
>>>
>>> Of course it does not increase the probability to get a "tails".
> Actually, it increases the probability that you'll get "heads" again.
>>
>>
>> Er, no, unless you assume that repeated flips of the coin in some way
> deform it so as to bias the outcome.

;) It was a joke. The link that I posted was supposed to make things clear. :)

On Friday, 10 October 2014 at 00:32:05 UTC, Joseph Rushton
Wakeling wrote:
> On Wednesday, 8 October 2014 at 07:40:14 UTC, eles wrote:
>> Of course it does not increase the probability to get a "tails". Actually, it increases the probability that you'll get "heads" again.

Did you see the link? ;;)