I also think propagating error would be better. But, current nothrow check is separated from purity/safety check, and if we return ErrorExp against purity/safety violation, it will *hide* nothrow error.

```
fail12622.d(23): Error: pure function 'fail12622.foo' cannot call impure function pointer 'fp'
fail12622.d(23): Error: safe function 'fail12622.foo' cannot call system function pointer 'fp'
fail12622.d(25): Error: pure function 'fail12622.foo' cannot call impure function pointer 'fp'
fail12622.d(25): Error: safe function 'fail12622.foo' cannot call system function pointer 'fp'
fail12622.d(27): Error: pure function 'fail12622.foo' cannot call impure function 'fail12622.bar'
fail12622.d(27): Error: safe function 'fail12622.foo' cannot call system function 'fail12622.bar'
fail12622.d(23): Error: 'fp' is not nothrow									// These errors will disappear
fail12622.d(25): Error: 'fp' is not nothrow									// if we return ErrorExp
fail12622.d(27): Error: 'fail12622.bar' is not nothrow						// against purity or safety
fail12622.d(19): Error: function 'fail12622.foo' is nothrow yet may throw	// violations.
```

I'd keep this code, because it would generate better diagnostic. And we can improve nothrow check mechanism in the future.