We noticed today when running a swift CLI program to a pipe that stdout is fully buffered (e.g. not unbuffered, not line-buffered). So just now we committed unbuffering IO to a bunch of CLI programs.
Is this the right default behavior for Swift?
I realize this is a Cism with a long history, but I think an argument can be made that the Cism is surprising (in that: it surprised us). I think most Swift developers would assume "print" to be line-buffered.
Requiring programs to opt-in to linebuffering so they can work via pipe feels wrong to me. Am I crazy?
Drew
gparker42
(Greg Parker)
2
We coincidentally got a Radar about this a few days ago.
func testExample() {
print("foo") // doesn't appear before the crash
assert(false)
}
Making print() less than fully buffered (either unconditionally or conditional on stdout being sufficiently terminal-like) ought to be reasonable. I mirrored the bug report to [SR-1127] print() should be less than fully buffered sometimes · Issue #43740 · apple/swift · GitHub .
···
On Apr 1, 2016, at 2:52 PM, Drew Crawford via swift-dev <swift-dev@swift.org> wrote:
We noticed today when running a swift CLI program to a pipe that stdout is fully buffered (e.g. not unbuffered, not line-buffered). So just now we committed unbuffering IO to a bunch of CLI programs.
Is this the right default behavior for Swift?
I realize this is a Cism with a long history, but I think an argument can be made that the Cism is surprising (in that: it surprised us). I think most Swift developers would assume "print" to be line-buffered.
Requiring programs to opt-in to linebuffering so they can work via pipe feels wrong to me. Am I crazy?
--
Greg Parker gparker@apple.com Runtime Wrangler
