iopipe alpha 0.0.1 version

[Martin Nowak]

On Thursday, 12 October 2017 at 04:22:01 UTC, Steven 
Schveighoffer wrote:
> I added a tag for iopipe and added it to the dub registry so 
> people can try it out.
>
> I didn't want to add it until I had fully documented and 
> unittested it.
>
> http://code.dlang.org/packages/iopipe
> https://github.com/schveiguy/iopipe

Great news to see continued work on this.

I'll just use this thread to get started on design discussions. 
If there is there a better place for that, let me know ;).

Questions/Ideas

- You can move docs out of the repo to fix search, e.g. by 
pushing them to a `gh-pages` branch of your repo. See 
https://github.com/MartinNowak/bloom/blob/736dc7a7ffcd2bbca7997f273a09e272e0484596/travis.sh#L13 for an automated setup using Travis-CI and ddox/scod.

- Standard device implementation?

   You library already has the notion of devices as thin 
abstractions over file/socket handles.
   Should we start with such an unbuffered IO library as 
foundation including support hooks for Fiber based event loops. 
Something along the lines of https://code.dlang.org/packages/io? 
Without a standard device lib, IOPipe could not be used in APIs.

   Easy enough to write, could be written over a weekend.

- What's the plan for @safe buffer/window invalidation, right now 
you're handing out raw access to internal buffers with an 
inherent memory safety problem.

   ```d
   auto w = f.window();
   f.extend(random());
   w[0]; // ⚡ dangling pointer ⚡
   ```

   I can see how the compiler could catch that if we'd go with 
compile-time enforced safety for RC and friends. But that's still 
unclear atm. and we might end up with a runtime RC/weak ptr 
mechanism instead, which wouldn't be too good a fit for that 
window mechanism.

- What about the principle that the caller should choose 
allocation/ownership?
   Having an extend methods means the IOPipe is responsible for 
growing/allocating buffers, so you'll end up with IOPipeMalloc, 
IOPipeGC, IOPipeAllocatorGrowExp (or their template 
alternatives), not very nice for APIs.

- Why continuous memory? The current implementations reallocs and 
even weirder memmoves data in extend.
   
https://github.com/schveiguy/iopipe/blob/3589a4c9fc72b844eb4efd3ae718773faf9ab9ed/source/iopipe/buffer.d#L171
   Shouldn't a modern IO library be as zero-copy as possible?
   The docs say random access, that should be supported by 
ringbuffers or lists/arrays of buffers. Any plans towards that 
direction?