I couldn't figure out a way to do this generically.

I have a lot of responses to this, starting with minimal changes, ending with let's change the standard library.

1. I'm actually fine with this, given that it's at least correct for this file, and it's a private function so it's not really exposed to much of anything.

2. Here's how to do what you wanted to do:

fn readNoEof(in: &io.FileInStream, sink: var) !void {
    switch (@typeId(@typeOf(sink)) {
        builtin.TypeId.Slice => {
            const T = @typeOf(sink).Child;
            ...
        },
        builtin.TypeId.Pointer => {
            const T = @typeOf(sink).Child;
            ...
        },
        else => @compileError("expected slice or pointer"),
    }
}

3. However, let's use this as an example to write idiomatic zig code. I think it would be better to separate this out into 2 functions:

fn readNoEof(in: &io.FileInStream, comptime T: type, result: []T) !void {
    return in.stream.readNoEof(([]u8)(result));
}
fn readOneNoEof(in: &io.FileInStream, comptime T: type, result: &T) !void {
    return readNoEof(in, T, result[0..1]);
}

related: #287

4. One more thing, this looks like it's a pretty common thing to want to do. Let's modify std.io.InStream to support these APIs. I think that it's ok to break backwards compatibility of readNoEof and give it a comptime parameter of the type you want to read. Existing callsites can be updated to get the old behavior by passing in u8.

   And then we can add a safety check, if you pass a struct type to readNoEof, it will give you a compile error if your struct is not packed (because you would get an undefined value when deserializing a non-packed struct).

   I think this macho code should be passing around a &std.io.InStream instead of the &std.io.FileInStream directly. This is where that readNoEof API would go. I understand that it's a little weird because you'd have to use var for the parameter due to error sets. That's In/OutStream design flaw introduced with new error set changes. #764 and we don't have a good solution for that yet (other than "just use var").

5. Finally, I think we should go back to (3) for now, because in order for (4) to make sense, we need the ability to specify endianness in packed structs. That's pending Add endianness as one of the pointer properties #649. Once packed structs support the concept of endianness, it makes sense to use them as types to serialization/deserialization functions.

Hope that helps!

My proposal is:

• do (3) since it's easy
• merge this PR since it's better than status quo
• I'll bump the priority of Add endianness as one of the pointer properties #649
• Once we get packed struct endianness working, we can add support for serializing/deserializing them using std.io.OutStream / std.io.InStream and then update this code to use std.io.InStream instead of std.io.FileInStream

good catch

I have a lot of responses to this, starting with minimal changes, ending with let's change the standard library.

1. I'm actually fine with this, given that it's at least correct for this file, and it's a private function so it's not really exposed to much of anything.

2. Here's how to do what you wanted to do:

fn readNoEof(in: &io.FileInStream, sink: var) !void {
    switch (@typeId(@typeOf(sink)) {
        builtin.TypeId.Slice => {
            const T = @typeOf(sink).Child;
            ...
        },
        builtin.TypeId.Pointer => {
            const T = @typeOf(sink).Child;
            ...
        },
        else => @compileError("expected slice or pointer"),
    }
}

3. However, let's use this as an example to write idiomatic zig code. I think it would be better to separate this out into 2 functions:

fn readNoEof(in: &io.FileInStream, comptime T: type, result: []T) !void {
    return in.stream.readNoEof(([]u8)(result));
}
fn readOneNoEof(in: &io.FileInStream, comptime T: type, result: &T) !void {
    return readNoEof(in, T, result[0..1]);
}

related: #287

4. One more thing, this looks like it's a pretty common thing to want to do. Let's modify std.io.InStream to support these APIs. I think that it's ok to break backwards compatibility of readNoEof and give it a comptime parameter of the type you want to read. Existing callsites can be updated to get the old behavior by passing in u8.

   And then we can add a safety check, if you pass a struct type to readNoEof, it will give you a compile error if your struct is not packed (because you would get an undefined value when deserializing a non-packed struct).

   I think this macho code should be passing around a &std.io.InStream instead of the &std.io.FileInStream directly. This is where that readNoEof API would go. I understand that it's a little weird because you'd have to use var for the parameter due to error sets. That's In/OutStream design flaw introduced with new error set changes. #764 and we don't have a good solution for that yet (other than "just use var").

5. Finally, I think we should go back to (3) for now, because in order for (4) to make sense, we need the ability to specify endianness in packed structs. That's pending Add endianness as one of the pointer properties #649. Once packed structs support the concept of endianness, it makes sense to use them as types to serialization/deserialization functions.

Hope that helps!

My proposal is:

• do (3) since it's easy
• merge this PR since it's better than status quo
• I'll bump the priority of Add endianness as one of the pointer properties #649
• Once we get packed struct endianness working, we can add support for serializing/deserializing them using std.io.OutStream / std.io.InStream and then update this code to use std.io.InStream instead of std.io.FileInStream