In/OutStream design flaw introduced with new error set changes.

[Hejsil]

So, before error sets, we had In/OutStreams that could be implemented on a memory buffer, files or whatever would fit this interface, and could function to take In/OutStreams, and it would work on all of these.

Now, with error sets, I can see that In/Outstream was redesigned to be generic, taking an error set as the parameter. This ruins the useability of the In/OutStream:

error: expected type '&OutStream(error)', found '&OutStream(error{SystemResources,OperationAborted,IoPending,BrokenPipe,Unexpected,WouldBlock,FileClosed,DestinationAddressRequired,DiskQuota,FileTooBig,InputOutput,NoSpaceLeft,AccessDenied,})'

Now, you would have to pass the error type to all functions taking an In/OutStream, for it to work again:

fn foo(comptime Error: type, stream: &io.OutStream(Error)) !void { ... }

If this is the way they should now be used, then can I be sure that foo doesn't explode into a million instances of foo, as different OutStreams are used? Users of my function now also have to call it like this:

const file_stream = FileOutStream.init(&file);
foo(@typeOf(file_stream).Error, &file_stream.stream);

Which, idk, seems not so ergonomic for the users of my library. It relies on the fact, that the implementer of the OutStream adaptor was kind enough to actually provide this Error constant field. If the implementer did not do this, the user is more screwed, and would have to write this code:

const file_stream = FileOutStream.init(&file);
foo(@typeOf(file_stream.stream.writeFn).ReturnType.ErrorSet, &file_stream.stream);

Ooh god, plz no.

[andrewrk]

Thanks for the early adoption. Let's get this sorted out.

doesn't explode into a million instances of foo, as different OutStreams are used?

This aspect should be fine. This isn't c++ where we duplicate all the work in every file and then rely on the linker to toss out redundant definitions. LLVM actually has an optimization pass that merges compatible function definitions together. We could potentially even notice when the difference between instantiations differs only in error sets and save time and space even in debug mode.

The API ergonomics and semantics on the other hand, let's talk about that.

Here are our options:

• OutStream can become non-generic again and use error as the error set, the void * equivalent of error sets. It then "poisons" other error sets, because the union of any error set and error is error. (This would be the equivalent to how it was before error sets merge)
• OutStream can become non-generic and only define a single error set - error{StreamingFailed} which is the error set for writeFn. This bubbles up to std.io.getStdOut() and you would not be able to distinguish between, for example error.BrokenPipe and error.NoSpaceLeft. It wouldn't make sense to hard code these errors into the OutStreamError set because you might make for example an OutStream on a memory buffer and then the only possible error should be OutOfMemory.
• You can use var as the type of the outstream parameter in your example like this: https://github.com/zig-lang/zig/blob/2c697e50db36e4f9c0af8b1a9d357deeb8f80026/std/debug/index.zig#L143
• I thought I had one more but I forgot. I'll keep thinking about it.

Sorry about all the breaking changes in a small amount of time. I've been trying to do the breaking changes all together and sooner to avoid even more pain later.

[Hejsil]

Actually, the code explosion is more a compile speed concern. foo could be big, and we might want to switch between loggers or something. EDIT: Ops, I guess I didn't read the last part about no difference in error sets optimization. That probably solves this.

Anyways, I think the ergonomics aspect is the bigger concern. I don't know the exact solution to this either, which is why I didn't propose anything. Something similar to var is probably what we want, where we can keep all our error code intact. Sadly, var throws away a lot of readability from the function signature. I don't want to propose some complicated "Concepts" feature, just so I can say foo takes any OutStream.

Maybe #470 is what would solve all of this? fn foo(stream: &OutStream(var)) !void, though I have no idea as to how this would work, as OutStream technically is a function being invoked at comptime to figure out the type.

[tiehuis]

Came across this a few weeks ago when doing a deflate implementation. https://github.com/tiehuis/zig-deflate/blob/master/deflate.zig#L99

This particular case was a bit more troublesome than simply taking a var however since I needed to also generate a wrapped type and store in the new case. Couldn't think of a way at the time to get the comptime Error from the type from a specific instance.