Recommended buffer size for the new IO?

[smlavine]

@Sze

With the case of your example, maybe somebody could write a Zig linter which you could run as a build step, that then rejects dependencies with fixed buffers that don’t have an explanation.

I don’t think there is necessarily one right way, but I think having it as a separate package would make it easier to spot such uses.

There also could be cases where some buffer will never get a better size (for example there could be algorithmic constraints), in such cases it would be better to add a comment that explains this, but if DefaultBufferSize is the low friction way to get a buffer, then maybe nobody will ever think about it long enough to discover that.

I disagree. The easiest way for people to learn Zig is to read Zig code. If you want people to learn to think about sizing a buffer appropriately according to their use case, then you are going to want them to read Zig code where people do that too. Arbitrary default provided by the standard library is better than arbitrary magic numbers sprinkled throughout codebases without documentation.

That is where my hesitancy comes from with adding things that may make things easy, but could lead to code that may be less simple than it could be. If some code can find some number of asserts that result in some ideal buffer size I find that strictly better than something picked arbitrarly, that is completely independent from what the program actually does with that buffer and may be picked by a number of people who write very different programs on very different hardware.

I don’t follow exactly how “simplicity” relates to this. Linters and secondary libraries and checking for asserts at runtime or whatever seems complex.

[smlavine]

Thanks for this guidance.

[smlavine]

Thanks for the context from this talk. Good resource.