Hacker News Reader

Comment by WalterBright | Hacker News Reader

We've tried various schemes like this with the D compiler. The sweet spot seems to be the current design, where new and possibly buggy/breaking features are introduced with the -preview=feature compiler switch. If it proves out, and users have time to adapt, eventually it becomes the default, and a -revert=feature is there for people who need more time to adapt to it.

This has so far been working great.

As John Carmack wrote, it enables us to be a little more fearless in introducing new capabilities and putting them on trial.

For example, my recent trial implementation of disallowing more than one mutable pointer to the same variable being passed to a function:

https://github.com/dlang/dmd/pull/10249

It's hard to tell in advance what effect this will have on the existing D user code base.

View on HN

Additionally, but on a slightly different note, I can think of two other common situations where these equivalence validation techniques are useful.

When refactoring or doing performance work, its very helpful to create two variant implementations, for instance the simple, obviously correct version and the new, optimized version. One can then send the output from a property based tester or a fuzzer into both implementations and test: assert forall x . referenceVersion(x) == optimizedVersion(x). A good property based tester or fuzzer will give one high confidence that behavior has been both understood and reproduced. Since changes to legacy code and bug fixes are among the primary causes of defect introduction, these testing techniques usually quickly bring to ones attention how fallible one is.

For non code artifacts like configurations and build systems where output is assembled or generated. The Unix diff utility can be useful. One assembles or generates the artifacts in two directories. One directory is representative of the project before the change and the second directory after the change. Anything that shows up in the directory diff should correspond to exactly to what one expected to see as a change. Since the full actions of package assembly and generation are often opaque, this technique provides assurance in parts of the system development process where there are often few other safety nets.

Additionally, for performance work you can put your performance expectations in a test: run both the old and new version, assert the perf. difference you want in addition to the result being the same.

> One can then send the output from a property based tester or a fuzzer into both implementations and test: assert forall x . referenceVersion(x) == optimizedVersion(x).

You can even do that in a production environment, assuming the "optimised version" is properly protected so it can't take down the entire system if there's an error in it.

Reply on news.ycombinator.com