iopipe alpha 0.0.1 version

[Martin Nowak]

On 10/13/2017 08:39 PM, Steven Schveighoffer wrote:
> What would be nice is a mechanism to detect this situation, since the
> above is both un- at safe and incorrect code.
> 
> Possibly you could instrument a window with a mechanism to check to see
> if it's still correct on every access, to be used when compiled in
> non-release mode for checking program correctness.
> 
> But in terms of @safe code in release mode, I think the only option is
> really to rely on the GC or reference counting to allow the window to
> still exist.

We should definitely find a @nogc solution to this, but it's a good
litmus test for the RC compiler support I'll work on.
Why do IOPipe have to hand over the window to the caller?
They could just implement the RandomAccessRange interface themselves.

Instead of
```d
auto w = f.window();
f.extend(random());
w[0];
```
you could only do
```d
f[0];
f.extend(random());
f[0]; // bug, but no memory corruption
```

This problem seems to be very similar to the Range vs. Iterators
difference, the former can perform bounds checks on indexing, the later
are inherently unsafe (with expensive runtime debug checks e.g. in VC++).
Similarly always accessing the buffer through IOPipe would allow cheap
bounds checking, and sure you could still offer IOPipe.ptr for unsafe code.

-Martin