Possible compiler issue

[donaldcallen]

I want to open an output file to which I can both simply write and also do a formatted print, the analogy to fprintf.

There really isn't any documentation yet for this, so I picked through the code in zig/std. In std/debug.zig, I find the getStderrStream function, which I used as a guide. After running into trouble, I excerpted the problem code into a little example.

const s = @import("std");
const f = s.fs.File;
const m = s.mem;

pub fn main() !void {
    const output_file_handle:f = try f.openWrite("/tmp/foo.bar");
    var output_file_stream = output_file_handle.outStream().stream;
    try output_file_stream.print("Hello {}\n", "World");
}

If I simply run this file, I get:

$ zig run testit.zig
Hello World
$

No compilation errors, but the output does not go to /tmp/foo.bar, but to stdout instead.

Realizing that io.Stream.print wants &self, I change the example:

const s = @import("std");
const f = s.fs.File;
const m = s.mem;

pub fn main() !void {
    const output_file_handle:f = try f.openWrite("/tmp/foo.bar");
    var output_file_stream = &output_file_handle.outStream().stream;
    try output_file_stream.print("Hello {}\n", "World");
}

$ zig run testit.zig
$ cat /tmp/foo.bar
Hello World
$

Now it works correctly.

But the print function is defined as

        pub fn print(self: *Self, comptime format: []const u8, args: ...) Error!void 

So I would have expected a type mis-match in compiling the first, incorrect version of the example. That's not what happened. It compiled without error and I got incorrect behavior instead.

[mikdusan]

See #591 -- this is a known footgun and an open issue. Please note the age of the case does not reflect how serious this issue is taken. It's just not a simple one to solve when considering the rest of the language - like sussing out interface support etc.

I would have expected a type mis-match

unfortunately for this case the types Foo and Foo* are equivalent in syntax for struct-method calls.

var obj: Foo = Foo{};
var ptr: *Foo = &obj;

obj.run();
ptr.run();

[donaldcallen]

Thanks for the explanation. I'm going to leave this open for Andrew et al to decide whether this issue adds anything to finding a solution to this.

As for your comment about the age of the case, I do understand that this project is a big job. I've looked at some of the release notes and see the progress that has been made. So I certainly don't have the impression that the developers have taken an extended vacation or aren't working on things that are important.

Speaking of which, I would like to bang the documentation drum again. In general, the current documentation, while it conveys a lot of information in few words, still really needs fleshing out in order to get to 1.0. And I'm not telling you anything you don't already know when I say that a standard library document should also be a high priority. I know -- there are more high priority items than people.

[andrewrk]

#591 remains open and it's one of the issues I want to address during this release cycle, with additional safety checks.