try/catch idiom in std.datetime

[Jonathan M Davis]

On Monday, November 18, 2013 12:47:32 Walter Bright wrote:
> On 11/18/2013 2:16 AM, 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;
> 
> I seriously object to this, as assert(0) is there for when you really do
> want an assert in release builds.
> 
> I.e.:
> 
> assert(!e); // removed in release builds
> if (e) assert(0); // stays in release builds
> 
> It's a valid D idiom, not a bug or oversight.

Then what would you suggest for dealing with cases where a nothrow function 
calls a function which can throw in general but can't throw with the given 
arguments? Completely separate from the issue of whether std.datetime should 
need to be calling a throwing function from a nothrow function as often as it 
does, it's still an issue which must be dealt with in general. At present, any 
nothrow function which wants to call a throwing function needs to use a try-
catch block to wrap the throwing function, and it makes good sense to use 
assert(0) to catch the case where the caller screwed up and the function can 
indeed throw. However, given that that throwing function should never throw, 
it's desirable to be able to optimize out the try-catch-assert(0). How would 
we do that without taking advantage of the fact that assert(0) indicates that 
that line of code should be unreachable?

If this were @safe, we would use @trusted, but this is nothrow, and there is 
no trusted-nothrow.

- Jonathan M Davis