[swift-evolution] Solving the issue of unit-testing precondition with the Standard Library?

[Dmitri Gribenko]

On Sat, Mar 12, 2016 at 4:26 PM, Dmitri Gribenko <gribozavr at gmail.com> wrote:
> On Sat, Mar 12, 2016 at 1:41 PM, David Hart via swift-evolution
> <swift-evolution at swift.org> wrote:
>> I am deeply interested in finding solutions for allowing unit-tests of preconditions. Without them, I believe we are leaving many holes in our tests and coverage. The solution found in the Swift project of forking the process seems fairly complicated to implement in XCTest.
>>
>> I found a solution online that works by overriding the precondition function with a function that calls a configurable closure which defaults to the original precondition function. It would be great if the Standard Library allowed this by default so that XCTest could use it to offer full support for precondition unit tests.
>>
>> http://stackoverflow.com/a/31349339
>>
>> Is this imaginable?
>
> What would precondition() if the condition evaluates to false, and the
> special handler is installed?  precondition() can't return, since it
> can't allow the original code to continue.  The original code
> certainly does not expect to continue (it can even do something
> memory-unsafe, or force-unwrap an nil optional, or advance an index
> past endIndex, etc.)

And, for the case of fatalError(), the compiler wouldn't even allow
you to return from a custom handler (since fatalError() is @noreturn).

I don't see a way around this.  If the code needs to stop, it will
make all sorts of assumptions about it (that it won't continue), and
so will the optimizer.

Dmitri

-- 
main(i,j){for(i=2;;i++){for(j=2;j<i;j++){if(!(i%j)){j=0;break;}}if
(j){printf("%d\n",i);}}} /*Dmitri Gribenko <gribozavr at gmail.com>*/