I wonder why it's `getStdOut` and `writer` and not `getStdOut` and `getWriter`, or just `stdOut` and `writer`. It seems inconsistent to me, but I might be missing something.
I think none of the API has been finalized, but in general getStdOut() returns a File, while .writer() returns the relative "interface" struct for writing. To read from stdin you do getStdIn().reader() for example. Also there's the possibility where you would want the File handle and not the reader/writer interface. So... the functions do different things and you don't necessarily string them together 100% of the time, other than that, I personally have no other opinion.
Also if you want to name a field for example like 'if' or 'for', then you can wrap it in @"" and it will be treated as a fieldname and no a keyword. Eg: const S = struct { @"if": i32 };
16:43 - But many C compilers are self-hosted, so it must be possible to do string formatting in C... But maybe it can't do error checking on the arg types, and instead it just plows through whatever you give it?
@@SamualN It's not i c though. printf (and the functions like it) use va_arg which you can do yourself just like in zig. Of course the compiler doesn't check the types or the count of arguments unlike zig, but you definitely can implement printf yourself in c
@@gingergoat3027 Im pretty sure that checking the format string is done by the compiler itself and not on the language level. You won't be able do get these type of compile time errors if you wrote your print function from scratch. You can only check the errors at runtime.
I agree that zig has made me think of the details. Amazing how I took for granted allocators and printf in C...
Good stuff - and btw, nice to see Sublime Text still being used
I was wondering what font is it on the terminal and editor ?
I wonder why it's `getStdOut` and `writer` and not `getStdOut` and `getWriter`, or just `stdOut` and `writer`. It seems inconsistent to me, but I might be missing something.
I think none of the API has been finalized, but in general getStdOut() returns a File, while .writer() returns the relative "interface" struct for writing. To read from stdin you do getStdIn().reader() for example. Also there's the possibility where you would want the File handle and not the reader/writer interface. So... the functions do different things and you don't necessarily string them together 100% of the time, other than that, I personally have no other opinion.
whats with the @ for the builtin?
That sigil is used for every builtin in Zig. It's how you know something you're reading is implemented by the compiler or by a user.
You can use it for language specific operations I suppose
Also if you want to name a field for example like 'if' or 'for', then you can wrap it in @"" and it will be treated as a fieldname and no a keyword. Eg:
const S = struct {
@"if": i32
};
16:43 - But many C compilers are self-hosted, so it must be possible to do string formatting in C... But maybe it can't do error checking on the arg types, and instead it just plows through whatever you give it?
he's talking about the special argument handling which is treated special by the compiler rather than like any other code
@@SamualN It's not i c though. printf (and the functions like it) use va_arg which you can do yourself just like in zig. Of course the compiler doesn't check the types or the count of arguments unlike zig, but you definitely can implement printf yourself in c
@@gingergoat3027 Im pretty sure that checking the format string is done by the compiler itself and not on the language level. You won't be able do get these type of compile time errors if you wrote your print function from scratch. You can only check the errors at runtime.
@@maksymiliank5135yeah for that, one would use c++ instead.
Couldn't find the source code on github, although I understand it's been 2 years or so