On Monday, November 18, 2013 10:24:11 Jacob Carlborg wrote:
> On 2013-11-18 10:18, Jonathan M Davis wrote:
> > I don't see much gain over simply putting scope(failure) at the top. You just avoid having to write the assertion yourself
> 
> You suggested it, but by adding it to the language instead.

True, but if the language did it, it could deal with it in a manner which compiled out the try-catch in -release mode as well as avoid the ugliness of wrapping the whole function body in a function call. Still, it would probably be better if we could get the compiler to recognize the idiom and compile out the try-catch in that case rather than adding something like that to the language. But I don't know how reasonable that is.

- Jonathan m Davis

"Andrei Alexandrescu" <SeeWebsiteForEmail@erdani.org> wrote in message news:l6ccae$2cmt$1@digitalmars.com...
> 1. Fix scope(failure) and then use it.

scope(failure) picks up Errors as well as Exceptions

On Monday, November 18, 2013 20:56:47 Daniel Murphy wrote:
> "Andrei Alexandrescu" <SeeWebsiteForEmail@erdani.org> wrote in message news:l6ccae$2cmt$1@digitalmars.com...
> 
> > 1. Fix scope(failure) and then use it.
> 
> scope(failure) picks up Errors as well as Exceptions

Ouch. That's true, which more or less kills that idea - though according to Walter, it's not supposed to be guaranteed to do so, and he'd probably prefer that it never did. But that's a whole debate in and of itself, and we've had it before.

- Jonathan M Davis

"Jonathan M Davis" <jmdavisProg@gmx.com> wrote in message news:mailman.59.1384769025.2552.digitalmars-d@puremagic.com...
> On Monday, November 18, 2013 20:56:47 Daniel Murphy wrote:
>> "Andrei Alexandrescu" <SeeWebsiteForEmail@erdani.org> wrote in message news:l6ccae$2cmt$1@digitalmars.com...
>>
>> > 1. Fix scope(failure) and then use it.
>>
>> scope(failure) picks up Errors as well as Exceptions
>
> Ouch. That's true, which more or less kills that idea - though according
> to
> Walter, it's not supposed to be guaranteed to do so, and he'd probably
> prefer
> that it never did. But that's a whole debate in and of itself, and we've
> had
> it before.
>
> - Jonathan M Davis

Yeah.  On the other hand, if we decide assert(0) means 'assume unreachable' we can optimize out the try-catch in release mode, among other things.

try { s } catch { assert(0); } -> s
if (e) assert(0); else s; -> e; s;

etc

On Monday, November 18, 2013 21:16:20 Daniel Murphy wrote:
> Yeah.  On the other hand, if we decide assert(0) means 'assume unreachable' we can optimize out the try-catch in release mode, among other things.
> 
> try { s } catch { assert(0); } -> s
> if (e) assert(0); else s; -> e; s;
> 
> etc

I was hoping that we could do something like that, since that would fix this problem as far as optimizations go. It leaves the slight verbosity of the try- catch, which is a bit annoying, but I wouldn't consider it all that big a deal, as nice as it would be to make it less verbose.

- Jonathan M Davis

On 2013-11-18 11:16, Daniel Murphy wrote:

> Yeah.  On the other hand, if we decide assert(0) means 'assume unreachable'
> we can optimize out the try-catch in release mode, among other things.
>
> try { s } catch { assert(0); } -> s
> if (e) assert(0); else s; -> e; s;

"assume" isn't the same as the compile will do this. Currently the spec says "Either AssertError is thrown at runtime if it is reachable, or the execution is halted". To me that means an implementation is free to throw an AssertError.

-- 
/Jacob Carlborg

On Monday, November 18, 2013 11:53:50 Jacob Carlborg wrote:
> On 2013-11-18 11:16, Daniel Murphy wrote:
> > Yeah.  On the other hand, if we decide assert(0) means 'assume
> > unreachable'
> > we can optimize out the try-catch in release mode, among other things.
> > 
> > try { s } catch { assert(0); } -> s
> > if (e) assert(0); else s; -> e; s;
> 
> "assume" isn't the same as the compile will do this. Currently the spec says "Either AssertError is thrown at runtime if it is reachable, or the execution is halted". To me that means an implementation is free to throw an AssertError.

assert(0) is intended specifically for use in cases where a line is supposed to be unreachable, and it wouldn't make any sense to use it in any other case, because assertion failures are intended to kill the program, and assert(0) always fails. It happens that it throws an AssertError in non-release mode in order to give you better debug information on failure, and it's a HLT instruction in release, but in either case, it's intended to be unreachable code.

The spec really should be updated to make it clear that when assertions are compiled in, assert(0) throws an AssertError and that when assertions are supposed to be compiled out, it becomes a HLT instruction. And if need be, we can update the spec to require that try-catches be compiled out when assertions are compiled out, and the catch's body only contains an assert(0).

- Jonathan M Davis

On 2013-11-18 12:03, Jonathan M Davis wrote:

> assert(0) is intended specifically for use in cases where a line is supposed to
> be unreachable, and it wouldn't make any sense to use it in any other case,
> because assertion failures are intended to kill the program, and assert(0)
> always fails. It happens that it throws an AssertError in non-release mode in
> order to give you better debug information on failure, and it's a HLT
> instruction in release, but in either case, it's intended to be unreachable
> code.
>
> The spec really should be updated to make it clear that when assertions are
> compiled in, assert(0) throws an AssertError and that when assertions are
> supposed to be compiled out, it becomes a HLT instruction. And if need be, we
> can update the spec to require that try-catches be compiled out when
> assertions are compiled out, and the catch's body only contains an assert(0).

Does all architectures support the HLT instruction or equivalent? The spec explicitly says HLT is used on x86.

-- 
/Jacob Carlborg

On 11/18/13 1:56 AM, Daniel Murphy wrote:
> "Andrei Alexandrescu" <SeeWebsiteForEmail@erdani.org> wrote in message
> news:l6ccae$2cmt$1@digitalmars.com...
>> 1. Fix scope(failure) and then use it.
>
> scope(failure) picks up Errors as well as Exceptions

That's fine. What the compiler should do for a nothrow function goes as follows. Consider:

void fun() nothrow
{
   statementsA
   scope(failure) statement
   statementsB
}

First off, statementsA must not throw. Then, if statementsB may throw, then look at what statement throws. If statement always throws an Error, then accept the code. This is because the scope(failure) effectively translates whatever exception into an Error, and it's legal for a nothrow function to throw Error.

Currently it looks like the presence of scope(failure) simply makes the function seem legit, no matter what.

void fun() nothrow
{
   scope(failure) {}
   throw new Exception("so sue me");
}


Andrei

As I understand, nothrow is used for minor optimization of exception handling, which doesn't help much if you hide mount of throwing code up the stack.