On Thursday, 12 October 2017 at 04:22:01 UTC, Steven
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
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 ;).
- 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.
auto w = f.window();
w; // ⚡ 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
- What about the principle that the caller should choose
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.
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